这次对谈里面提到的一个点，我觉得很有启发 —— 设立一个 buffer（一个 md文档，作为问题的缓冲区），当 agent 发现一段代码有改进空间时，不要立刻改进，而是记录在 buffer 中， 一段时间后统一处理 如果只优化单一问题，很有可能陷入局部细节改进。但如果Agent的一次上下文中能够看到一批问题，很可能就能找到一种共性的解决

作为 Grok 的 外宣，poteto 上个月的 token 消耗是 1.5T（150 万个“百万 token”），按如下估算： - 她使用的 3 种模型按一半 Grok、一半 Opus/Sol - 75% cache read、15% 输入、10% 输出 - 给个极限的团队 token 采购 1 折价格 大约 $ 0.2/M，150 万 × $0.2 ≈ $30 万 一个月合入2500 个 PR 背后的 token 成本大概率超过 30w 刀 em...

表面上看，TDD红绿重构的流程能将 测试 作为需求实现的硬门槛（红灯没法继续推进），但实际情况是：agent 为了推进实现，有强烈意愿去构造 expect(true) 的废用例 核心问题在于 —— 你不能将用例当作代码实现的免费添头 更具体来说，代码是在 spec 指导下实现的。类似的，用例也需要在指导下实现 不同类型用例的来源不同，单测的来源是“代码实现”，e2e 的来源是用户行为。 如果你采用 BDD 的开发模式，那 spec 中确定的用户行为天然可以作为 e2e 的指导，这样生成的用例才是可用的

测试用例的问题是“大部分人（甚至 agent 的默认执行流程也是）将它当作 代码实现后的免费添头” 这么做的后果是：用例变成对源码的第三人称复述 “从代码到测试用例”其实和“从 spec 到 代码”一样，需要单独的工作流（而不是免费添头）。用例和代码一样也会腐败、冗余，需要定期维护、精简 前者甚至比后者重要得多，因为对 AI Coding 来说 code is cheap，重要的是信任，好的测试用例是信任的基石 基于此，当下社区的风潮是“不再考虑传统软件工程的测试金字塔，而是聚焦在 e2e” 因为通过设计 spec，某种程度上你可以在代码实现的同时兼顾用例质量（通过 BDD），这是对投入精力的权衡 并不是说 单元测试 不再重要，而是没有精力维护“好的单元测试”

我发现只会 Vibe Coding 的程序员会被淘汰，因为：AI 提效 的效率基数不是「与不用 AI 古法编程比」，而是「与团队中效率最高的程序员比」 基于上述前提，为什么 Vibe Coding 会遇到效率瓶颈，因为并发很难提高，人的注意力是瓶颈 为什么不敢放手（减少注意力投入），因为不信任 agent 产出 为什么不信任，因为注意力关注不到的地方就是黑盒 而新的程序员工作模式，是把项目当作一个「信任框架」，程序员负责维护框架（给 agent 提供脚手架、工作流、对外验证的接口...） agent 负责在受限的框架中实现需求，并用框架提供的验证工具证明自己的工作成果值得被信任，证明之前犯过的错不会再犯...

总结下 如何让 Agent 遵守你定的规则？ 从宏观、微观 2 个维度讲，宏观的原则是： > 将规则分离为“工程化的确定性”与“Agent 语义理解的不确定性” 举个前者的例子： “我希望 Agent 生成的代码不要太复杂” 这句话可以解释为“单个模块代码不要超过 500 行”，可以实现为 lint 规则，当 Agent 生成超过 500 行的模块代码时，lint 报错，Agent 借此纠偏 不能被工程化确定的规则，才考虑写成给 Agent 的规范，比如：“开发时应遵循 TDD”就没法被工程化确定，只能作为给 Agent 的规范。 宏观维度确定了“什么给工程化，什么给 Agent”，微观维度则是指：规范应该怎么暴露给 Agent？梳理下常见的暴露点： 1. 最高优：AGENTS.md 2. 渐进披露：Skill 中 3. 各种可能被路由到的规范文档 4. 各种 Agent 的执行规范文档（比如 Spec、Ticket、PRD），甚至是简单的计划模式 5. 脚本执行后输出给 Agent 看的提示 不要拘泥于类似“AGENTS.md 该怎么怎么写”，核心原则是： > 对你来说越重要的规范，就在 Agent 面前暴露越多次，次数越多，被遵循的概率越高 举例： 你希望“测试时不要一个测试失败，修复后就从头跑，应该从失败的开始继续跑”，可以： 1. 在 AGENTS.md 中暴露一次 2. 改造测试脚本，每当 agent 执行测试时，脚本会输出 agentHint 参数，指导 agent 测试时应遵守的约束，再暴露一次 agentHint 示例： “如果当前 session 反复执行多次测试，当修复失败用例后，应该从失败用例继续跑，最终全部通过后再整体跑一遍” 甚至更进一步，记录项目的测试执行情况，当发现符合上述调用规律时，agentHint 直接要求从失败用例继续跑。

总结一个宏观规律： 引导 Agent 按 你定的规范 执行的关键不在于单一设计（类似 AGENTS.md 该怎么规划、文档怎么路由），而在于： 越重要的规范，应该在 Agent 面前暴露越多次，次数越多，被遵循的概率越高 比如，你可以在 AGENTS.md 中提到过，当 Agent 执行到相关操作时，对应脚本执行后也可以再提醒 Agent 一遍

如果你希望 Agent 编码时遵循规则，不要在 AGENTS.md、Skill 或 各类文档中写规则（类似：当 xxx，你应该 yyy），模型底层是概率，长程执行中规则被执行的概率会越来越低 正确做法：用工程化的确定性对抗概率的不确定性。 举例：你希望“测试时不要一个测试失败，修复后就从头跑，应该从失败的开始继续跑”，那不应该在文档里许愿，而是改造测试脚本，每当 agent 执行测试时，脚本会输出 agentHint 参数，指导 agent 测试时应遵守的约束。 举例： agentHint：“如果当前 session 反复执行多次测试，当修复失败用例后，应该从失败用例继续跑，最终全部通过后再整体跑一遍” 甚至更进一步，记录项目的测试执行情况，当发现符合上述调用规律时，agentHint 直接要求从失败用例继续跑。 编码各种流程的约束都收敛到脚本的 agentHint 参数中， AGENTS.md 及各类文档中只需要强调一句话：执行过程中遇到 agentHint，要参考他的建议

AI Coding 高质 & 高效 的一个重要因素是 约定俗成 很多同学喜欢给 agent 加各种实现规范，其实没有必要，靠约定俗成即可。举个例子： 你希望实现的接口报错有详细的错误信息、准确的错误码，前端能根据交互类型用不同方式展示错误信息。 除了用规范约束外，还可以先正常迭代，等积累了足够接口时，再统一处理。处理完后项目就形成了“错误处理等约定俗成”，后续实现即使没有规范，Agent 也会按约定俗成来处理

如果你在用 Grill-Me 对齐需求，给你推荐一种更高效的方式 本质来说，Grill-Me 是人与 Agent 就一棵需求树进行 BFS 遍历对齐，之所以要遍历每个节点，是因为如果人类漏掉一些节点，那“人类理解”与“Agent 实现”之间就会产生偏差。 但逐个节点对齐确实页很耗时间。 你可以针对需求设计一个 AFK循环，让 Agent 对 需求进行 grill 迭代，直到他认为完全对齐 你再对齐产出的 PRD，对不满意的部分进行剪枝并重新对齐 这样能在一定程度上保证 偏差控制 的前提下，极大提高效率 这么做可行的前提是： 1. 项目已经迭代一段时间，有些约定俗成的文档、代码供 Agent 参考 2. AFK循环 的目标、通过条件 设计的合理

对于 GPT Astra 这种 Computer Use 能力很强的模型，“模型的前端设计能力”这个概念需要被改写了。 之前的含义：模型生成网站的前端 UI 是否好看、高级 现在： 1. 提供一个风格参考 2. Astra 遍历全站，识别所有 UI 3. 对所有 UI 按参考风格生图 4. 基于生图重构 UI 5. Astra 走查实际效果，不通过就回到 4 6. 循环结束后全站 UI 都是符合风格的 一句话概括 —— 模型的前端设计能力 的下限是“模型自身前端能力”，上限是“模型生图的审美”，完成度靠 Computer Use 能力保证

对于“需不需要学习 应用层面的 AI 知识”，存在 2 个有趣的悖论： 1. AI 发展太快，相关知识只要你不学，你就不用学了 2. 掌握最新 AI 知识的白领，产出效率/质量会显著高于其他同行

用 Astra 和其他没那么聪明的模型最大区别是什么？ 最高效的工作模式没变化，都是 AFK（away from keyboard）即：写明背景、目标、工作流程、通过条件，然后让 agent 跑循环 区别是 后者的工作流程要写清楚，Astra 你可以写：自己想办法

AI Coding 能力已经很强了，很多 Review 出来的 bug 并不是由于编码失误产生的，而是因为「需求没有完全对齐，AI 必须脑补完整需求，导致实现与需求产生偏差」 ，这些偏差被以 bug 的形式在 Review 时被发现。 一句话总结：bug 的本质是需求没对齐～ Review 的意义不在于「发现了多少 bug」，因为总会有需求细节没对齐。其最大的意义在于「是否发现了宏观、架构层面的 bug」 发现这类 bug 预示着你的需求对齐流程存在严重瑕疵，导致 宏观、架构层面的偏差产生，最终在 Review 时被以 bug 的形式报出来。 这时候你应该完善需求对齐流程。

这是个很有洞察的观点，我想提出些不同的观点： AI Coding 能力已经很强了，很多 Review 出来的 bug 并不是由于编码失误产生的，而是因为「需求没有完全对齐，AI 必须脑补完整需求，导致实现与需求产生偏差」 “架构缺陷”这种重大问题的根源是「没有对齐需求」，所以解决办法应该是从「需求对齐侧」下手，而不是带着偏差进入实现，再靠 Review 来发现偏差 Review 的作用更多是「宏观上对齐了需求，但是遗落了细节，Review 发现了这些细节偏差」

matt/skills 最终结局会怎样呢？他的理念会被 Agent Harness 吸收，导致装机率逐渐减少 因为：类似 codex App（现在叫 chatGPT App）的迭代方向都是：把 coding Agent 作为底座，在上面增加办公场景的抽象层。下一个被加入的抽象层应该是「基于 issue 的流程 kanban」 那么 issue 从哪来呢？Plan Mode 就需要加入「从需求转issue 的 tooling」 那 issue 怎么分类呢？根据需求类型分类，比如： - 需要与其他同事讨论的 - 需要自己做原型的 - 需要联网调研的 这些其实就对应 matt/skills 现在的一系列 skill