入行这段时间，我用 AI 写代码的方式换了好几轮：从什么都问，到堆 Skill、堆流程，再到最近动手把大部分流程删掉。正好把这几个月的折腾整理成一篇复盘，也算给自己留个存档。
我在组里主要做 Agent 开发，也维护一部分后端业务。下面写的不是标准答案，就是我自己踩了一圈坑之后留下来的顺手流程，挑有用的看就行。这篇文章也放在云栈社区做个记录。
为什么开始给工作流做减法
一开始我走的是“多给约束”的路子。GPT-5.4 和 Opus 4.6 那会儿，模型刚能在给足上下文的前提下把任务做像样，Harness Engineering 的说法也火了起来，我跟着装了一整套 Superpowers：Spec、TDD、强制工作流，什么需求都按流程走。
头几个复杂需求确实香，流程替我把关，返工少。但很快账就来了：一个不大的改动，光走流程就烧掉一大截 token。更别扭的是，明明上下文已经够了、可以直接开写，模型还是按既定步骤一步一步演完，像在给流程陪跑。
转变发生在模型升级之后。新模型不再需要那么多护栏，原先觉得“稳”的约束，反而成了拖慢它的绳子。后来 OpenAI 发 Astra 时专门写了篇博客，讲怎么清理多余的 Skill 和系统提示词——等于官方也承认了这件事：约束不是越多越好。
所以现在我的原则很简单：流程只留两种——一种是帮我自己想清楚的，一种是帮模型拿到真实反馈的。其余的，能删就删。
我常用的 Skill 和 Prompt
工具怎么分工
编码主力是 Codex + GPT-5.6 Sol；规划交给 Astra（它出来之前由 GPT-5.6 Sol Max 兼职）。小需求用不着大炮，pi + DeepSeek V4 Flash 就能干。
对抗性审查和 Code Review 这类要唱反调的活，交给 Claude 5 Fable——换一个模型来看同一段代码，比让写它的模型自我检讨靠谱。个人项目里的大方案设计，我习惯开网页端 GPT-6 Pro 慢慢磨。
留下来的几个 Skill
brainstorming：obra 的 Superpowers 里的一环，动手写代码之前先把思路聊开——目标、边界、备选方案，聊透再动工。重流程的 Skill 我基本拆完了，就留了这个，它帮的是我想清楚，不是替模型画跑道。（它和 grill 的分工：brainstorming 用在需求还没成型时发散，grill 用在方案已经成型后挑刺。）
grill me / grill with docs：Matt Pocock 写的需求拷问器。自己觉得方案已经想清楚了？交给它连着追问几轮，总会冒出一两个没想过的坑。结论我习惯落进 ADR 或 CONTEXT.md，省得口头共识过夜就变味。
implement：同一个作者的 Skill，跟 grill 是一对。计划一旦定了就不再讨论，按 Issue 直接开干。
ponytail：专治过度设计。模型写嗨了会堆出一堆抽象层，跑一遍它能删掉大半，我 Review 的血压也跟着降下来。
handoff：跨工具接力。把当前上下文整理成一个文件带走，从 Codex 切到 Claude Code 或 pi agent 继续干，不用人肉复述前情提要。
check：提 MR 之前过一遍的代码自查。
自己攒的 Skill：比如端到端测试的固定步骤、发布前的检查清单。我的阈值是三：一个流程手动做满三次，就让 Codex 整理成 Skill 存下来，下次直接叫。
比 Skill 更好用的：思维快捷键
大段 Prompt 我现在基本不手写了，需要时让 Codex 整理。比如多轮讨论完想把上下文交给 GPT Pro 做方案设计，就先让 Codex 生成一份完整的交接 Prompt。
真正天天在用的是几类很短的 Prompt，经常一句话顶几千字。我管它们叫思维快捷键。
原理其实不难理解：这些不是什么魔法咒语，而是人类知识里早就高度标准化的方法论。模型训练时见过海量的相关论文、代码、设计文档和讨论，所以很多时候不用手写几百行 Workflow，只要告诉它该用哪套思考方式。下面几个是我实践下来最好用的：
第一性原理。别顺着现有方案继续优化，回到问题本身重新问一遍。举个常见的例子：搜索接口慢，团队的第一反应是“上 Elasticsearch”。我把话头拦下来，换了个问法——
不要基于“引入 Elasticsearch”这个既定方案继续设计。从第一性原理分析这个搜索接口为什么慢，以及最小必要的解决方案。
模型于是开始拆：瓶颈到底是 SQL 的 LIKE 全表扫描、深分页，还是每次请求都在实时聚合？拆完发现数据量才几十万行，一个联合索引加改写分页方式，耗时直接进百毫秒。几十万的数据引入一套 ES，等于为了换个灯泡把房子重装了一遍。
怀疑“题目本身就问错了”的时候，用这个。
对抗性审查。不帮方案找理由，专挑能推翻它的反例。把“帮我看看这个技术方案有没有问题”换成——
对这个方案做一次对抗性审查，优先寻找能推翻核心假设的反例。
比如方案是“为了扛秒杀流量，引入消息队列削峰”，它就不再陪你讨论 MQ 参数怎么调，而是开始掀桌：峰值 QPS 实测过吗，还是拍的？当前数据库的压测上限是多少，真扛不住吗？引入 MQ 之后，消费失败怎么重试、消息积压了怎么办、订单状态的一致性谁来兜底？是不是为了一个一年就两次的峰值，给系统养了一辈子要喂饭的中间件？
方案评审和 Code Review 特别适合用它——尤其当方案听起来“很正确”的时候。
消融实验。系统变好了，不代表你加的每样东西都有用。一次性能优化往往好几招一起上，最后说不清功劳算谁的。比如列表页从 1.2s 压到 250ms，中间同时做了接口合并、字段裁剪、Redis 缓存三件事，直接问：
给这三个优化设计消融实验，判断真正的收益来自哪里。
模型会设计一组对照：从 Baseline 出发逐项加回。跑完常常发现，只做字段裁剪就已经到 400ms，缓存再贡献 150ms，接口合并几乎白做。功劳簿一摊开，哪些代码值得留、哪些纯属给未来埋雷，一目了然。
奥卡姆剃刀。效果差不多时，选假设更少、复杂度更低的。比如要防止用户重复领券，Agent 给你整出 Redis 分布式锁 + 唯一索引 + 状态机 + 定时对账补偿的全家桶，补一句：
用奥卡姆剃刀重新审查这个设计，在满足需求的前提下，删除所有非必要机制。
它多半会发现：领券就是单库写入，一条唯一索引加幂等插入就够了，锁和补偿都是给想象中的并发准备的。这条对现在的 Coding Agent 尤其管用——模型太容易为了“显得完整”而过度设计了。
高内聚、低耦合。重新检查职责和边界。比如一个 ExportService 涨到 2000 行，同时管着拼查询条件、生成 Excel、上传对象存储、发通知邮件、记操作日志，就问：
按高内聚、低耦合原则审查 ExportService 的职责边界，不要为了拆而拆。
模型会开始盘：哪些属于“导出”这个领域本身？生成文件算，上传和发通知其实是通用能力，该下沉给独立的模块；查询条件的拼装也许根本不该它管。它激活的不是“拆文件”，是一整套关于模块化、信息隐藏、依赖方向的判断。
所以我现在很少再写“第一步分析需求、第二步检查假设、第三步寻找替代方案”这种东西。方法论模型早就学过了，我只需要说：
从第一性原理重新分析，对当前方案做对抗性审查；核心机制必须通过消融实验验证；方案遵循奥卡姆剃刀，代码保持高内聚、低耦合。
几十个字，背后是五种认知动作：重新定义问题、攻击假设、验证贡献、删除复杂度、整理系统边界。
新模型时代的 Prompt Engineering，我觉得变化就在这：与其写死一套完整流程，不如用准确的方法论告诉它该用什么方式思考，再补上当前任务真正必要的约束。
我的日常开发工作流
整条流水线可以概括成三道关：把需求对齐好，把任务分发好，把结果验证好。
第一道关：对齐。 拿到需求，先把手里所有相关材料丢给 Agent——PRD、会议纪要、群聊记录、用户反馈，有什么给什么——让 grill 接着盘。这些材料凑在一起往往互相打架：PRD 常常落后于最新的讨论，口头定下的限制散落在纪要和群聊里，连我自己对需求的理解都掺着没验证的假设。让 Agent 结合团队 Wiki 和现有代码去消化，连续追问，把会影响实现的目标、边界和取舍问清楚。有的我当场答，有的得回头找产品确认。
这里有个尺度要拿捏：追问到“剩下的问题不会再改变实现方向和验收结果”就可以收了。别指望它把所有实现细节提前规划好，不然需求对齐自己先变成一套重流程。
对齐的结论落进 Spec 或 CONTEXT.md：这次解决什么问题、范围多大、关键决策是什么、验收标准长什么样。后面负责实现和审查的 Agent 直接共享这份文档，不用翻完全部聊天记录。
第二道关：执行。 主 Agent 按复杂度分流。简单的直接实现；复杂的拆成边界清楚、能独立验收的 Issue，能独立推进的部分丢给 subagent 在各自的 worktree 里并行跑，主 Agent 最后收口集成。编码 Agent 先写测试再写实现——顺序反了，测试就成了摆设。它觉得能交付了，再引入别的 Agent 做一轮交叉对抗性审查，问题统一攒给 Codex 修，修完重新验证。
第三道关：验证。 我自己 Review 之前还有一道端到端测试。
说实话我现在基本不逐行读生成的代码了，主要看两样：测试结果和核心业务逻辑。前提有两个——每次 MR 范围足够小，以及随着开发推进逐步验证完整的业务路径。小 MR 让每次要理解和判断的改动可控；端到端测试确认改动放进真实业务流程还成立。剩下的人工 Review 就集中在业务逻辑上，顺便掂量现有测试够不够撑起这次交付。
Agent 友好的端到端测试环境
单测再漂亮，也只证明代码符合它自己的想象。测试写得越多，越容易产生“质量有保障”的错觉——上线后撞到的往往不是逻辑 bug，而是流程接起来才暴露的问题。这类问题在编码阶段根本没机会被发现，因为 Agent 看不到真实的系统。
所以我干的第一件基建活，就是把业务的端到端测试环境打通：Agent 能从真实入口把业务流程跑一遍，自己检查结果对不对。有了这个，我才敢让它写的代码进主干。
环境要怎么搭？我把它拆成四个能力：
① 环境要能起：一键拉起环境、一键造数据，版本、账号、权限写清楚，随时清场重来。
② 系统要能操作：通过浏览器、API 或 CLI 把真实业务流程跑起来，不是只调几个接口。
③ 证据要能取：只读 DB MCP 确认落库，日志 Skill 和 Trace 捞链路状态、报错现场。
④ 流程要能沉淀：稳定操作写成脚本，排障方法整理成 Skill，别每次重新摸索。
再补几个踩出来的细节：
浏览器自动化值得投入。 业务流程绕不开页面的，推荐 ego lite 这个开源浏览器，轻快好用。配 pi agent + DeepSeek V4 Flash，一轮测试跑下来很快。
把零散操作收进一个 CLI。 Skill、MCP、脚本各自为政的时候，Agent 光找入口就要折腾半天。整合成一个测试 CLI：环境检查、数据准备、场景执行、结果查询、清理，一条命令一个动作。这东西顺手就成了团队的提效工具——我做完之后，平时排障自己也用。
工具负责拿证据，不负责下结论。 DB 查询确认状态，日志和 Trace 解释失败原因，但“预期结果是什么”必须来自业务契约。证据和答案要分开：前者交给工具，后者只能来自需求。
被测产品本身是 Agent 的话，还得评答案质量。 流程跑通只是及格线，回答得好不好要靠 Agent Eval 那一套，这里先不展开。
怎么 Review AI 写的代码
写得再快，签字画押的还是人。Review 这道关省不掉——省掉的都会在生产环境找回来。分享几条我自己定的规矩：
先对验收标准，再看测试结果。 拿 Agent 写的验收标准当索引，对照端到端测试的结果逐条核：该验的验了吗？结果对得上吗？别被“92% 通过率”这种数字安抚——要通过的不是测试的百分比，是这次需求真正在乎的那些事。
火力集中在高风险路径。 权限、状态流转、并发、重试、数据一致性、迁移和回滚，这几类是线上事故的常客，逐行看都值得。模式稳定的 CRUD 可以放过——这部分我现在已经直接跳过了。
新长出来的抽象要单独过堂。 每次新增的基类、中间层、通用机制，都用奥卡姆剃刀的思路让 AI 再审一遍：它防的那口锅真的存在吗？有没有更便宜的做法？很多复杂度都是“以防万一”四个字堆出来的。
MR 多到审不动，就造 Review Bot。 组内 MR 密集的话，值得做一个专门的 Review Bot 承担交叉审查。它和前面手动调 pi agent / Claude Code 挑刺不同，重点是把 Git 变更信息和一套预先设计好的审查清单绑在一起，做成可重复、专供 MR 的自动化审查。
总结和思考
用了几个月，最大的体感是：瓶颈早就不是“写得快不快”，是“审得动不动不了”。Agent 可以同时推五个任务，但我理解业务、判断方案、确认交付的速度一分不会多。只让它可劲写，攒下来的不是进度，是一座等着审的 PR 山。
所以下一步我想做的是：把重复问题拦在我伸手之前。类型检查、测试、业务断言能抓住的，让 Agent 在开发过程中自己消化；真正到我这儿的，只剩三件事——需求理解没理解对、关键业务逻辑成不成立、还有哪些没验证过的风险。
Review Bot 是这道防线的主力，但衡量它别看评论条数，看两样：有效问题有没有少漏，我的负担有没有真变轻。
这几个月下来，我对 Harness 的理解也落了地。把日常自测里反复做的动作固化成 CLI、脚本和 Skill，它就能自己把系统跑起来、把结果查出来、把失败证据找出来。这些资产下个任务还能用，也能直接递给同事。
Harness 不只是给模型喂对上下文，还包括给它一个能动手的环境，和一把能对答案的尺子。
另外，工作流要定期断舍离。有些步骤是为了补某一代模型的短板而存在的，模型升级了，就要回头掂量它们还有没有存在价值。简单任务直接做，复杂任务再上规划、拆分、交叉审查那套。Astra 更新之后，我就把 AGENTS.md 里几条过严的约束删了——模型在迭代，工作流不能刻舟求剑。
当然，测试和 Review 只是压低不确定性，验收标准本身还得人来定。代码和测试互相自洽、却一起误解了需求的事，完全可能发生。端到端测试覆盖的也只是选定的环境和场景，生产环境的流量、并发、数据分布，永远能给你新的惊喜。
最后说点心里话。我工作不久，本来指望靠踩坑攒领域经验，但 AI 把大部分坑提前填了——那些原本要熬几个大夜排查才能换来的顿悟，现在常常变成一句“我错了，现在修改一下”。所以我每天刻意留一段时间学习和复盘，也想清楚了一个问题：AI 把“把代码写出来”变廉价之后，研发同学真正的价值在哪儿。
这篇是几个月实践的存档，适用边界我自己也还在摸。你要想试试，别急着搭大环境——先挑一条最常走的自测路径，让 Agent 独立跑通一遍、把证据留下，再把好用的步骤沉淀下来，就有了第一块砖。
发表于 6 小时前
|
查看: 1|
回复: 0
