ARTICLE · 1143155
AI 辅助软件工程
AI 辅助软件工程AI 是新的范式，但软件工程的基本功（尤其是那些为了和人协作而生的纪律）在 AI 时代反而更好用。不要追求「AI-native 新方法论」，回到《重构》《务实程序员》《设计的设计》《软件设计的哲学》这些老书里已经讲透的原则，把它们用自然语言「翻译」成给 Agent 的提示词即可。 注意力关系是平方级增长的：每多一个 token，模型要处理的「两两关系」就爆炸式增加。 不管上下文窗口是 200K 还是 1M，大概 100K token 之后就开始变傻，越长越笨，直到做出蠢决策。 含义：把任务切小，让每个任务都落在聪明区内；别让 AI「一口吃成胖子」。 1M 上下文窗口的本质 = 「给你发了一大坨更长的傻区」，对检索有用，对写代码帮助有限。 每次清空上下文，模型就重置回初始状态（只剩 system prompt）。 演讲者讨厌 compact（压缩），更喜欢「清上下文、回到起点」——因为那个起点状态每次都一样、可控、可优化。 system prompt 要尽量小（有人塞 250K 进去，等于一上来就进傻区）。 想法 → [Grill Me 对齐] → PRD(目的地文档) → Kanban(可并行 issue) → [人类离场] AFK Agent 实现 → [人类回场] QA + Code Review ↑___________________ 团队可来回争论、出原型 ___________________↑ ↑ 发现新问题再补 issue 回 Kanban 核心不是「写规格文档让 AI 转代码」，而是先和 AI 达成共享理解（design concept）。 grill me skill 极短：「 relentless 地盘问计划的每个方面，逐个 branch 走决策树，每题先给推荐答案，一次只问一个」。 会一直追问（演讲者见过的：40 / 80 / 100 题都有），逼你把没想清楚的点想清楚（例如「历史学习记录要不要回溯补分？」）。 这个对话本身就成了资产——可以喂会议录音进去一起盘假设。 关键分类：Human-in-the-loop（必须人在环）任务 vs AFK（人可离场）任务。对齐阶段必须人在环，实现阶段可以 AFK。 PRD 只是把对齐到的 design concept 总结成「我们要去哪」。 演讲者基本不读 PRD——因为 LLM 很会总结，既然已经同频，读 PRD 只是在测它的总结能力。 PRD 包含：问题陈述、解决方案、user stories、实现决策、测试决策、以及out-of-scope（不做什么）——后者对「完成的定义」很关键。 把 PRD 拆成互相独立、可并行认领的 issue，带 blocking 关系 → 本质是 DAG（有向无环图），可多 Agent 并行。 反对「多阶段顺序计划（phase 1→2→3）」：顺序计划只能一个 Agent 串着跑。 Vertical slice（垂直切片）vs Horizontal（水平切片）： 水平：先做完所有 DB 层、再做所有 API 层、最后前端——要等到第 3 阶段才有反馈。 垂直：每个切片横跨所有层（schema 改一点 + 新 service + 前端最小可见表示），第一轮结束就能看到东西、拿到反馈。 名字来自「tracer bullet（曳光弹）」——黑夜射击时每几发带磷光，让你看见弹道、即时校准。 ralph once.sh：把本地 issue 文件 cat 进变量 + 最近 5 条 commit + prompt，用 claude --permission-mode accept-edits 跑。 AFK 版在 Docker 沙箱里循环：挑下一个 AFK issue（优先级：关键 bug > 基建 > tracer bullet > 打磨/重构）→ explore → TDD 实现 → 跑反馈循环 → 直到无任务。 这就是「日班（人规划）/ 夜班（AI 实现）」模型：人在前面把活儿排好队，交给 AI 离线干。 实现完了人类必须手动 QA（尤其前端）——这是把你的审美/判断/口味强加回代码库的唯一方式。 全自动化每一环 → 出来的东西「缺品味、是 slop（垃圾）」。人要留一手。 QA 中发现的毛病 → 变成新 issue 回填 Kanban，循环无限延展。 现实： delegation 越多，code review 量只增不减，要做好心理准备。 Red-Green-Refactor：先写失败测试，再让实现通过。 好处：自动给代码库补好测试；且 AI 很难作弊（它得先 instrumentation 再写实现，而不是「先把实现写完、再在下面补一层测试」那种偷懒）。 反馈循环（feedback loop）是 AI 能力的天花板：你的代码库反馈循环越差，AI 输出越烂；没有测试/类型检查，AI 就是瞎写。 同一上下文里让 AI 审自己写的代码 = 审的人在「傻区」，比实现时还笨。 正确做法：先 clear 上下文，再用一个干净的 session 审 —— 审的人在聪明区。 演讲者用 Sonnet 实现、用 Opus 审（审需要更多智力）。 引自 John Ousterhout《软件设计的哲学》：深模块 = 小接口、大功能；浅模块 = 一堆导出很多东西的小文件。 AI 天然倾向于产出浅模块（难导航、难测、测试边界混乱）。 要把代码库设计得「易测」 → 反馈循环才好 → AI 才做得好。 心智技巧：设计好模块接口，把实现委托给 AI；模块当「灰盒」——你只需知道它行为和边界，不必通读内部。这样既能快，又不丢对代码库的掌控感。 配套 skill：improve code base architecture——扫描代码库、找能把浅模块「加深」的地方。演讲者安利：在你 repo 上跑一次试试。 Push：把指令常驻塞给模型（如 Claude.md「像海盗说话」），每次都发。 Pull：给 Agent 一个「按需拉取」的机会（如 skill，带描述头「需要时再调」）。 实践：实现阶段用 pull（Agent 有疑问自行查规范）；自动审查阶段用 push（把编码规范压给 reviewer，让它拿着规范和代码对比）。 演讲者写的 TypeScript 库，把串行 Ralph 循环升级为并行： planner 看 backlog + blocking 关系，选一批可并行 issue； 每个 issue 开一个 Docker 沙箱 worktree（独立 git branch）跑 implementer； 有 commit 就交给 merger agent 合并，冲突/类型/测试问题它自己修。 一句话：规划用 Kanban 表达依赖，执行用沙箱隔离，合并用专门 agent。 Doc rot（文档腐烂）：PRD 留仓库里，一个月后代码早变样，旧 PRD 反而误导 Agent。演讲者倾向做完就扔（GitHub 上 mark closed，留个「已完成」视觉标记即可）。 前端 / 原型：前端是多模态、极度依赖人眼。别指望 Agent 用 Playwright 看页面就做出好 UI。做法：让 AI 吐 3 个 throwaway 原型路由让你挑，再把挑中的喂回 grilling。原型本就该脏、本就该早给反馈。 Own your stack（控制反转）：框架很多（Spec Kit / Open Spec / Taskmaster…），但格局未定，规划栈要尽量自己掌握，否则出了问题你连怎么修都不知道。 Sub agent：子 Agent 有独立上下文，干完活只把摘要「滴灌」回主 Agent，省主上下文 token。 AI 不替代工程纪律，它放大工程纪律——老书里的方法现在是给 Agent 的提示词素材库。 先对齐，再写码：grill me 达成共享理解，远比 spec-to-code 靠谱。 垂直切片 + 小任务 + 强反馈循环（TDD/类型/测试） 是让 AI 出活的三件套；反馈循环质量是能力上限。 深模块：把代码库设计得易测，就是给 AI 铺好跑道；浅模块是 AI 的泥潭。 人在环的关键节点是「对齐」和「QA/审查」；中间实现可 AFK，但品味和判断不能外包，否则产出 slop。 grill me —— 盘问式对齐，逼出 design concept write a PRD —— 总结成目的地文档（含 out-of-scope） PRD to issues（Kanban）—— 用 vertical slices 拆可并行 issue（本地 markdown，不强制 GitHub） ralph once.sh / AFK loop —— Docker 沙箱里循环实现 improve code base architecture —— 扫描并加深浅模块 Sandcastle —— 并行化框架（planner + 沙箱 implementer + merger）