Posts

当所有人都声称自己解决了 AI 编程的「失控」问题时，真正的失控才刚刚开始。 2026 年 3 月，AI 编程框架的竞争进入了一个诡异的阶段。Superpowers 用「技能强制」约束过程，GSD 用「状态机」约束环境，gstack 用「角色分工」约束视角，OpenAI 的 Harness Engineering 则用「声明式编排」约束意图。它们都在做同一件事：给失控的 Agent 套上缰绳。 但问题在于——约束不是解决方案，而是问题的转移。 据我们了解，Superpowers 在 GitHub 上已积累 3.15 万+ stars1，gstack 发布数天内即获得约 2 万 stars2，Harness Engineering 相关仓库在 3 个月内激增到 107 个3。然而，一位同时深度使用过这四套系统的资深工程师告诉我们：「它们都在解决同一个症状（Agent 失控），却没人敢碰真正的病因（Agent 不理解）。」 这场「约束竞赛」的本质是什么？各家方法的边界在哪里？以及，为什么它们都离「真正的自主工程」还有距离？ Superpowers：用「强制技能」约束过程，但谁来约束技能？ Superpowers 的思路很直接：既然 Agent 会乱来，那就让它「必须」按规矩来。 这个由 Jesse Vincent（obra）创建的框架4，核心机制是「技能强制触发」——在 SKILL.md 文件中写入类似 “You MUST use this before any creative work” 的指令，Agent 在检测到对应意图时，必须优先触发技能，而非直接编码。截至 2026 年 1 月，它已被 Anthropic 官方接入 Claude Code 插件市场5。 这套机制的本质是「过程约束」。 它强制 Agent 遵循 RED-GREEN-REFACTOR 的 TDD 循环，强制在编码前完成设计文档，强制通过子 Agent 进行代码审查。一位使用 Superpowers 的 Tech Lead 表示：「它确实减少了『拍脑袋编码』的情况，我们的代码规范遵守率从 60% 提升到了 90%。」 ...

当 AI Agent 能够连续运行数天、自主管理复杂工程任务时，Web Coding 的竞争规则已经变了。 2026 年开年，AI 编程工具的讨论焦点正在从「能写多少代码」转向「能持续跑多久」。以 Cursor Composer 为代表的新一代工具，正在探索「multi-day autonomy」（多日自主性）——让 Agent 在没有人工干预的情况下连续运行数天，处理从代码生成到架构设计的全流程任务。这不是简单的「自动化」，而是一场关于 Agent 「记忆力」和「决策力」的工程实验。 据我们了解，Cursor 团队在 2026 年 3 月发布的 Composer 2 版本1，将上下文窗口扩展至 20 万 Token，并引入了「会话记忆」「上下文压缩」等能力，试图解决长期运行中的致命问题：上下文爆炸和错误累积。传统 AI 编程在几小时后就会因为上下文过长而「失忆」，而新一代技术通过智能压缩和总结机制，让 Agent 的「有效记忆」远远超出物理窗口限制。 一位接近 Cursor 的工程师透露，他们的目标不是替代程序员写代码，而是构建「能够自主进化的代码仓库」——让软件工程从「人驱动」转向「AI 驱动」。 从「写代码」到「做工程」：Agent 的能力跃迁 过去两年，AI 编程工具的竞争集中在「生成速度」和「代码质量」上。GitHub Copilot 能在几秒内补全代码，Claude Code 能在 6 小时内自主调试复杂系统，但这些仍属于「短跑」——任务明确、时间可控、上下文有限。 Cursor 的长运行能力则将「长跑」推向了「week-scale」（周级）。据行业观察，Composer 的 Agent 模式能够支持长时间复杂任务执行，提供会话记忆、上下文压缩、分支聊天、代理调试面板等能力2。更要紧的是，这些 Agent 并非简单执行预设任务，而是能够自主规划、分工协作、迭代优化。 这种能力的本质是什么？ 一位长期研究 AI 编程的研究者指出，关键不在于「写代码」本身，而在于「维持工程状态的连续性」。人类工程师的价值不仅在于写代码，更在于对系统架构的理解、对历史决策的记忆、对错误模式的识别。Agent 要想替代这部分工作，必须拥有「长期记忆」和「渐进式学习」能力。 Cursor 的解决方案是「Hierarchical Agents」（分层 Agent）架构：Planner（规划者）负责拆解任务、Worker（执行者）负责具体实现、Judge（评判者）负责质量把关。三层之间通过压缩后的上下文传递信息，既避免了信息过载，又保持了决策连贯性。 记忆，是 Agent 工程化的最大瓶颈 当前 AI 编程工具面临的核心挑战，不是「能不能写」，而是「记不记得住」。 据我们了解，大多数 AI 编程 Agent 在持续运行 4-6 小时后就会出现明显的「失忆」症状：忘记之前的架构决策、重复已修复的错误、对代码库的整体理解逐渐模糊。这是因为大模型的上下文窗口有限，而代码仓库的信息密度极高，几小时的对话就会填满「内存」。 ...

领导力不是职位特权，而是一种「让别人心甘情愿做你想做的事」的元能力。它不分层级，不论场景，是每个人终其一生都可以修炼的功课。 今天参加了一场领导力培训。开场前有个细节让我印象深刻：讲师没有问"在座多少人是管理者"，而是问"有多少人希望自己更有影响力"。全场举手。 那一刻我突然意识到，我们对领导力的理解，可能从一开始就窄化了。 领导力的祛魅：从职位到元能力 传统观念里，领导力似乎专属于那些带团队、管项目的人。但培训中的第一个观点就颠覆了这个认知： 领导力是每个人都拥有的影响力——你影响家人周末去哪里吃饭，影响朋友接受你的建议，影响同事支持你的方案。这些时刻，你都在运用领导力。 这让我想到一个更本质的定义：领导力的核心，是「让别人做你想做的事」。 注意，不是"替别人做事"，不是"命令别人做事"，而是让别人心甘情愿地，朝着你想去的方向行动。这里面藏着两层深意：一是你要清楚自己想要什么（方向感），二是你要理解别人为何愿意跟随你（影响力）。 高段位的领导者，从来不是最忙的那个人。他们善于授权——把Ownership真正交给团队，让每个人都觉得"这是我的事"。低段位的管理者，往往陷在事务里亲力亲为，团队却动力涣散。 管理与领导：性恶论与性善论的分野 培训中最精彩的部分，是把管理和领导放在了哲学的高度对比。 管理基于性恶论——它假设人需要规则约束，需要流程规范，需要考核驱动。管理的逻辑是"怕你做错"，所以设定边界、监控过程、追求确定性。管理问的是：如何正确地做事？ 领导基于性善论——它相信人有向善的潜力，有自发的创造力，有追求卓越的本能。领导的逻辑是"信你能成"，所以描绘愿景、创造机会、拥抱不确定性。领导问的是：如何做正确的事？ 这两者的关系不是对立，而是分形。 面对不成熟的团队（新人居多、能力不足、方向不清），你需要管理——建立规则、明确流程、降低试错成本。这时候团队是"团伙"状态：成员相似度高、目标短期功利、依赖外部驱动。 面对成熟的团队（能力匹配、目标共识、自我驱动），你需要领导——激发潜能、授权决策、容忍试错。这时候团队才是"团队"状态：成员能力互补、目标长远积极、内在动机驱动。 最危险的领导者，是用管理成熟团队的方式带新人（放任自流），或用带新人的方式管成熟团队（过度控制）。 领导与领导力：职位与能力的错位 培训中有个扎心的案例：某大厂总监，管着两百人的团队，却发现关键时刻没人真正听他的。他拥有最大的「职权」，却缺乏最基本的「影响力」。 这揭示了一个残酷真相：领导职位是组织赋予的，领导力却是他人授予的。 有职位的人，天然拥有通过职权影响他人的权力——你可以分配任务、决定薪酬、影响晋升。但这种影响力是交易型的：下属听你的，是因为你手里有他想要的东西。 真正的领导力是感召型的：别人听你的，是因为信任你的判断、认同你的价值观、愿意和你一起赌一个不确定的未来。 职权领导力在顺境时好用，逆境时失灵。非职权领导力——基于专业、品格、愿景的影响力——才是穿越周期的硬通货。 这也解释了为什么有些创业者在资源匮乏时能凝聚团队：他们没有职权筹码，只能靠Ownership的让渡和愿景的感召来凝聚人。这种"赤手空拳"练出来的领导力，往往比大公司高管的"职权惯性"更扎实。 领导力的习得：从知到行的鸿沟 培训最后抛出一个问题：领导力可以教会吗？ 答案是：可以学习，无法教授。 课堂上可以讲清楚概念、模型、工具，但真正的领导力只能在真实的博弈中长出来。当你被逼到墙角不得不决策，当你要为他人的错误兜底，当你必须在信息不足时选择方向——这些时刻，领导力才开始生长。 现代领导力理论强调结果论：不管你用什么风格，能否持续为组织创造卓越业绩，是检验领导力的唯一标准。 但这不意味着领导力是少数人的天赋。恰恰相反，每一次你主动承担责任，每一次你把"这是我的问题"说出口，每一次你在不确定中选择相信团队，你都在修炼领导力。 培训结束时，我想起一句话：领导力的终极考验，不是你能爬多高，而是当你跌落时，还有多少人愿意托住你。 职位可以任命，权力可以继承，但那种让人心甘情愿跟随的力量——那种即使你不发号施令，团队也会向着共同方向奔跑的感召力——只能靠自己一次次站在悬崖边，一次次选择不后退，一次次把"我们一起扛"说出口，才能慢慢长出来。 这或许是领导力最公平的地方：它不问出身，不论起点，只问你是否愿意为他人承担不确定性。

原文：Harrison Chase, How Coding Agents Are Reshaping Engineering, Product and Design, LangChain Blog, 2026 年 3 月。以下为编译，保留原文结构与论点，部分段落做了压缩和意译。 软件公司里的 EPD——工程（Engineering）、产品（Product）、设计（Design）——存在的目的只有一个：造出能用的软件。角色分得再细，最终交付物也只是代码。 认清这一点很重要，因为 Coding Agents 突然让写代码变得极其廉价。那么，EPD 的角色会怎么变？ PRDs 已死 在 Coding Agent 出现之前，PRD（产品需求文档）是软件开发的起点。标准流程是一条清晰的瀑布： 有人（通常是 PM）冒出一个想法 PM 写 PRD 设计师根据 PRD 画 Mock 工程师把 Mock 变成代码 这不是铁律——创业公司里这些步骤经常混在一起，最好的 Builder 能一个人跨好几个环节。但之所以还有这条「标准流程」，是因为写软件和画 Mock 都需要大量时间。于是产生了专业分工，也产生了跨分工沟通的需求。PRD 就是这个沟通的起点，一切从这里瀑布到设计，再瀑布到工程。 Coding Agents 改变了这一切。它们可以把一个想法直接变成能跑的软件。所以当我（和其他人）说「PRDs 已死」，真正的意思是：这种以写 PRD 为起点的传统软件开发方式已死。 瓶颈从实现转向审查 任何人现在都能写代码，也就意味着任何人都能做东西。但这不代表做出来的东西架构良好，不代表解决了正确的问题，也不代表好用。 工程、产品和设计应该成为这些维度的审查者和仲裁者。生成的代码并不总是「好的」，EPD 的角色变成了审查并确保它是「好的」。「好的」意味着： 工程视角：架构是否可扩展、高性能、健壮？ 产品视角：是否真正解决了用户痛点？ 设计视角：界面是否易用、直观？ 由于生成初版代码的成本极低，原型数量大幅增加。这些原型成为焦点，EPD 围着它们审查。 问题在于——生成代码太容易了。以前写代码需要时间，审查者桌上同时摆的项目有限。现在任何人都能写代码，在做的项目数量在膨胀。我们在三个职能中看到的瓶颈都是同一个：审查——拿着原型，确保它们是「好的」。 PRDs 万岁 以写 PRD 为起点的旧流程死了，但描述产品需求的文档依然必不可少。 假设有人冒出一个想法，快速生成了一个原型。这个原型怎么进生产？它需要 EPD 其他成员审查。审查时，一份书面文档总是有帮助的，甚至是必需的——别人看代码时，怎么知道某段代码是手误还是有意为之？这取决于意图，而意图需要被传达。 ...

声明：本文纯属虚构。数据是真的，人是真的，会议是编的。如有雷同，说明百度确实该开这个会。 下午三点半，百度大厦 E 座 23 层，Robin 的助理敲了三下门。 “Robin，港股收盘了。” “嗯。” “MiniMax 收涨 22%。市值 3826 亿港元。” “我们呢？” “3322 亿。” Robin 放下手里的 iPad。屏幕上是海螺 AI 生成的一段视频——一只金毛犬在沙滩上奔跑，毛发在逆光中一根一根地飘。他刚才用文心一格试了三次，出来的狗像穿了件塑料雨衣。 “叫人。” “叫谁？” “所有 VP。” 助理犹豫了一下：“Robin，现在是 OKR 对齐周，大家都在——” “我说叫人。OKR 对齐个屁，先对齐一下市值。” 会议室的灯亮了。六个人陆续到齐。 Dou 穿着卫衣，上面印着"AI Native"——百度去年团建发的。Jackson 系着领带，手里端着瑞幸。Haifeng 带了笔记本电脑，屏幕上开着飞桨的 dashboard，仿佛随时准备汇报技术指标。 Robin 把一张纸推到桌中间。上面手写了两行字： MiniMax：4 岁，收入 7900 万美元，73% 海外，市值 3800 亿。 百度：26 岁，收入千亿，AI 砸了近千亿，市值 3300 亿。 “谁来给我拉齐一下认知？” Dou 条件反射地接话：“Robin，市值不完全反映——” “对，市值不反映基本面。但你知道市值反映什么吗？反映 narrative。MiniMax 的 narrative 是什么？一个中国公司，七成收入来自海外，两亿多用户遍布 200 个国家。人家没在国内卷，没烧钱买量，没搞百亿补贴。人家润出去了。” 他停了一下。 “我们的 narrative 是什么？” 没人说话。 “我来帮你们 align 一下：百度是中国最早布局 AI 的公司，拥有从芯片到框架到模型到应用的全栈能力，文心大模型 5.0 在 LMArena 排名国内第一——” ...