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 发现了这些细节偏差」

一个新需求，包括 4 个端，花了一周时间对齐所有需求（17 个 issue），现在开始从 0 实现，不知道要跑多久，也不知道实现的效果 怪期待的

今天和学员聊到「AI 设计还原」话题，在我看来这不是个技术问题，而是工作交接问题。最高保真的方式是设计一个「设计同学使用的工作流」： 1. RD 提供一个原型环境 2. 设计靠 agent 拉取原型环境代码，本地打开 dev，然后vibe coding 原型 3. 满意后提交分支到远端，再在 issue 中更新 分支信息 接下来 RD 根据分支的代码重构成符合项目规范即可

看了 @indie_maker_fox 的分享，这周也在尝试花了 4 天时间完整对齐 MVP 的所有需求，接下来就看 /implement 会跑多久了 主要想验证下影响 AI Coding 质量的是不是 2 个因素： 1. 项目初始基建，包括架构和测试基建 2. 需求对齐程度

side chat 高效工作法：利用 codex side chat 一段时间不使用会过期销毁的特性，在 side chat 中执行重要工作，以此强迫自己必须高效

随着 Agent 编程能力提升，需求实现侧最终会退化为简单的 /goal 命令。 但是，为了保证软件长期迭代时需求没有由于偏差而被破坏，需要“能够准确校验需求的测试用例”。 所以当下和未来，开发工作流 关于 需求实现侧 的大部分逻辑都会围绕“如何让 Agent 实现需求的同时能产出高质量测试用例” 比如：Matt/skills 的 Seam -> Tracer Bullet -> TDD

当你要从 0 用 AI Coding 开发项目时，最重要的是什么？是 “不要从 0 开发项目” 《人月神话》提到：概念完整性是系统设计中最重要的考虑因素。 最佳策略是：基于一个“已经具有概念完整性的模版项目”开始开发。 概念完整性 = 统一的概念模型 + 一致的设计原则 + 迭代时遵守前序原则 为什么 mattpocock/skill 中要记录 CONTEXT.md 与 ADR？本质来说： - 前者属于 统一的概念模型 - 实现需求时参考后者是为了一致的设计原则

问了我的编辑老师，现在一本 AI 的书最快 2 个月就出了，实际时间可能更快 背后的主要原因并不是“慢了书里的 AI 知识就过时了”，因为买书的人也不会看，纯缓解焦虑 主要原因是商场书店 C 位就那么一小块，不可能摆好几本不同出版社、不同作者讲 DeepSeek Harness 的书 这么看，写书真是门好生意，书里塞个二维码引流，这可比 9.9元体验课 效果好多了

个人观点：需求开发工作流最忌讳「包含过多内部机制」，比如：有辅助的内部脚本会在不同 skill、agent hook 中调用 如果目的是“提升最终生成的代码质量”，那这种努力最终会被“Agent 能力提升”抹平 如果目的是“团队间、Agent与人之间的协同”，那应该放到协同平台（类似 Github、slack、飞书）这一层解决

学员问我为啥老是聊 mattpocock/skills，基于 2 个事实： 1. Agent 发展很快，很多复杂的优化操作会被 Agent 能力提升抹平 2. AI 编程的未来是“不编程”，编程问题 最终会上升到 工程和项目管理问题 可以得出结论 —— 选择工作流要满足： 1. 模块分明、实现简单：Agent 发展时能随时移除“被 Agent 能力抹平的模块”，且可以像搭积木一样自定义 2. 面向工程：面向 issue 的设计是 编程问题 转为 工程问题 的桥梁 基于此，mattpocock 当前是最适合的

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