用 5 条短 Prompt 替掉重 Skill：一位大厂 Agent 开发者的日常 AI 工作流

这篇文章的起点是一次组内分享。作者 @huangtongxueh 入职大厂两个月，做 Agent 开发，同时维护已有的后端业务；他所在组的老板对「他怎么用 AI 工具、怎么搭个人 Harness、AI Coding 的工作流长什么样」很感兴趣，于是他把自己这几个月的做法整理成文。

他说得很直白：自己现在做需求又快又好，已经是一些项目的主 O（Owner），所以借这次机会整理了一下日常的 AI 工作流。这篇文章的主线是做减法。

文章涉及的层面	具体内容
工具分工	编码、规划、审查、简单需求分别交给不同的 Agent
指令层	7 个常用 Skill；5 条短 Prompt 替代大段 Workflow
流程层	从需求对齐到交叉审查的日常开发工作流
环境层	一套 Agent 自己能跑的端到端测试环境（MCP / CLI / Skill）
人的把关	Review AI 代码的 4 条实践，以及「验收标准必须来自业务契约」

一、为什么要做减法：重 Skill 正在变成模型的噪声

作者之前在小红书分享过相关的工作流。当时的背景是 GPT-5.4 和 Opus 4.6 已经能在获得准确上下文和合理约束的情况下很好地完成任务；Harness Engineering 的兴起，也让更多人意识到可以通过增加约束来更好地驾驭一个强大的模型。

比如 Superpowers 这类 Skill，就提供了一套比较重的实现，主要围绕 Spec 和 TDD，帮大家更容易地组织和推进任务。

但这么做有弊端，他感受最明显的是 Token 消耗得快。像 Superpowers 这样的 Skill 里包含很多用于约束模型下一步行动的 Workflow——哪怕从全局看某个步骤已经没有必要了（上下文已经足够、可以直接开始实现），模型仍然可能沿着既定流程继续执行。

随着新模型发布，他看到不少开发者开始分享：自己已经基本不用这些很重的 Skill 了。一个主要原因是，模型能力增强之后，一些原本被认为有用的约束和流程，正在变成模型的噪声。他举的例子是：OpenAI 在发布 Astra 时，专门写了一篇博客，介绍如何清理不必要的 Skill 和系统提示词，以改善模型的使用体验。

二、工具分工：哪件事交给哪个 Agent

他按任务性质把活分给不同工具：

任务	工具	备注
编码实现	Codex + GPT-5.6 Sol	主力
方案规划	Astra	Astra 发布前主要交给 GPT-5.6 Sol Max
简单需求实现	pi + DeepSeek V4 Flash	轻量、便宜、够快
对抗性审查、Code Review	Claude 5 Fable	方案的对抗性审查
个人项目的方案设计	网页端 GPT-6 Pro	只用在个人项目里

三、常用的 7 个 Skill

他列出的 Skill 大多不是自己写的，而是社区现成的，加自己在工作里沉淀的 SOP：

Skill	干什么用
think	tw93 的 Skill，主要用来做方案对齐和头脑风暴
grill me / grill with docs	需求澄清：通过连续追问，把目标、约束和取舍问清楚，再按开发流程的需要沉淀到 ADR 或 CONTEXT.md 中。它能挖出前期对齐时没想到的问题
implement	配合 grill 使用，属于 Matt Pocock 的 Skills 全家桶，用于实现已经明确的计划或 Issue
ponytail	清理 AI 的过度设计，降低 Review 难度。作者经常用——因为 GPT-5.6 Sol 很多时候会过度设计
handoff	把当前上下文整理成文件，方便在新会话里继续任务。他一般用它从 Codex 交接给 Claude Code 或 pi agent
check	代码审查，一般在提 MR 的时候使用
自己沉淀的 Skill	主要是一些可复用的流程 SOP，比如端到端测试

关于最后一条，他给了一条很具体的经验：日常工作里，一个流程重复超过三次，就可以考虑让 Codex 帮你整理成 Skill，之后直接复用。

至于大段 Prompt，他现在已经很少自己写了。有需要时通常让 Codex 整理——比如经过多轮讨论后，想把当前上下文交给 GPT Pro 做方案设计，就先让 Codex 生成一份完整的交接 Prompt。

四、5 条短 Prompt：把方法论当「思维快捷键」

他常用的另一类东西是很短的 Prompt，有时能起到「一句话顶几千句话」的效果。他把它们理解成模型的「思维快捷键」。

它们不是魔法咒语，而是一些已经在人类知识中高度标准化的方法论。模型在训练过程中见过大量相关论文、代码、设计文档和讨论，所以很多时候不需要再手写几百行 Workflow，只需要告诉它采用哪套思考方式。

4.1 第一性原理：不要沿着现有方案继续优化

适用场景：你怀疑「题目本身可能就问错了」的时候。比如一个接口很慢：

不要基于"加 Redis 缓存"这个既定方案继续设计。从第一性原理分析这个接口为什么慢，以及最小必要的解决方案。

模型的关注点就会从「Redis 应该怎么设计」，切换成：

瓶颈到底在 SQL、网络、序列化、锁竞争，还是重复计算？如果给 SQL 加一个索引就能解决，为什么还要引入 Redis？

4.2 对抗性审查：不要帮我的方案找理由

普通的问法是「帮我看看这个技术方案有没有问题」，可以换成：

对这个方案做一次对抗性审查，优先寻找能推翻核心假设的反例。

假设方案是「为了解决重复请求，引入分布式锁」，模型就不再只是告诉你锁的超时时间该怎么设，而是开始追问：

重复请求真的需要互斥吗？接口幂等能不能解决？锁服务挂了怎么办？锁过期了，但业务还没执行完怎么办？是不是为了解决一个局部问题，又引入了新的分布式故障点？

作者说这类 Prompt 特别适合方案评审和 Code Review。

4.3 消融实验：系统变好了，不代表你加的每一个东西都有用

一次做了三个优化：

加索引、Redis 缓存和批量查询后，接口耗时从 800ms 降到了 100ms。

这时候直接问：

给这三个优化设计消融实验，判断真正的收益来自哪里。

模型就会围绕不同组合设计对照，比如以 Baseline 为起点，比较只加索引、索引 + 缓存、索引 + 缓存 + 批量查询等组合。最后可能发现：

只加索引，就已经把耗时从 800ms 降到了 120ms，剩下两个复杂方案只贡献了 20ms。

这样你就更清楚哪些代码值得保留，哪些复杂度可能没有必要。

4.4 奥卡姆剃刀：效果差不多时，选假设更少、复杂度更低的方案

如果 Agent 给你设计了这样一套东西：

Kafka + Redis + 分布式锁 + 状态机 + 定时补偿。

可以补一句：

用奥卡姆剃刀重新审查这个设计，在满足需求的前提下，删除所有非必要机制。

很多时候它最后会发现：当前场景只有单库写入，一个事务加唯一索引就够了。作者说这句话对现在的 Coding Agent 尤其有用，因为模型很容易为了「完整」而过度设计。

4.5 高内聚、低耦合：重新检查代码的职责和边界

比如发现一个 OrderService 已经有 2000 行：

按高内聚、低耦合原则审查 OrderService 的职责边界，不要为了拆而拆。

模型通常会开始检查：

为什么订单服务同时负责库存、优惠券、短信、支付和报表？哪些逻辑属于订单领域本身，哪些应该通过稳定接口交给其他模块？

它激活的不是简单的「拆文件」，而是一整套关于模块化、信息隐藏、依赖方向和职责划分的判断。

4.6 小结：几十个字，背后是五种认知动作

作者现在很少再写「第一步分析需求，第二步检查假设，第三步寻找替代方案，第四步……」这种流程化的 Prompt，而是直接给出方法论：

从第一性原理重新分析，对当前方案做对抗性审查；核心机制必须通过消融实验验证；方案遵循奥卡姆剃刀，代码保持高内聚、低耦合。

这几十个字，实际上指定了五种不同的认知动作：

重新定义问题 → 攻击假设 → 验证贡献 → 删除复杂度 → 整理系统边界

这也是他理解的新模型时代 Prompt Engineering 的一个变化：与其给模型写死一套完整的思考流程，不如用准确的方法论告诉它「应该以什么方式思考」，再补充当前任务真正必要的约束。

五、日常开发工作流：从需求到合并

第一步，把上下文交给 Agent。 拿到需求后，他会先把相关材料给 Agent——PRD、会议纪要、聊天记录、用户反馈——然后用 grill 做需求对齐。

第二步，承认材料是不完整的。 这些材料往往并不是一份完整、一致的需求：PRD 可能没更新，会议里可能补充过限制，聊天里又调整过优先级；他自己对需求的理解，也可能包含一些没有说出来的假设。

所以他会让 Agent 结合团队 Wiki 和现有代码理解这些材料，再通过连续追问，把会影响实现的目标、边界和取舍问清楚。有些问题能当场回答，有些需要回头找产品或相关同学确认。

这里他控制一个尺度：当剩下的问题已经不会显著改变实现方向和验收结果时，就可以开始开发了。 他不会要求把所有实现细节都提前规划好——否则需求对齐本身又会变成一套很重的流程。

第三步，对齐结论落盘。 结论会沉淀到 Spec 或 CONTEXT.md 中，主要记录这次要解决的问题、范围、关键决策和验收标准。这样后续负责实现和审查的 Agent 能共享同一份上下文，不需要重新读完之前的全部对话。

第四步，按复杂度决定怎么执行。 方案确定后，由主 Agent 根据任务复杂度决定：简单需求直接实现；复杂需求拆成边界清楚、可以独立验收的 Issue。只有能独立推进的部分，才交给 subagent 在不同的 worktree 中并行开发，最后由主 Agent 负责集成。

第五步，编码 Agent 先完成测试。 等它认为已经可以交付时，作者再根据任务复杂度，引入其他 Agent 做交叉对抗性审查。发现的问题统一反馈给主编码 Agent（也就是 Codex），由它修复并重新验证。

第六步，他自己 Review 之前，还会做端到端测试。 他现在不会逐行阅读所有生成的代码，主要看测试结果和核心业务逻辑。这里有一个很重要的前提：每次 MR 的范围都足够小，并且随着开发推进逐步验证完整的业务路径。

小 MR 让每次需要理解和判断的改动保持在可控范围内；端到端测试则帮助他检查这些改动放进真实业务流程之后是否成立。人工 Review 时，他再重点确认业务逻辑，以及现有测试结果是否足以支持这次交付。

六、怎么构建 Agent 友好的端到端测试

AI 已经很擅长写测试用例了，动不动就给一个 Bugfix 写上几百行测试（作者点名了 5.6 sol）。多写测试本身没有问题，但部署上线后，还是会遇到预期之外的错误。

他判断核心问题是：没有给 Agent 提供端到端的测试环境，让它有机会在编码和自测阶段就发现这些问题。 如果能把这样的环境搭起来，让 Agent 可以从测试环境的真实入口执行任务，一直检查到用户需要的结果，就可以比较放心地让 AI 写的代码运行在真实系统中。

在实际开发中，他已经为业务搭了一套端到端开发测试环境：Agent 可以方便地查库表、查日志，也能连接机器排查问题。整个搭建过程其实就是让 Agent 提炼他日常开发自测的流程，把散落的工具和能力集成起来——能工具化的能力，就做成 MCP 或 CLI；可以复用的流程，就写成 Skill。

这件事前期确实需要花一些功夫，但不要怕麻烦。搭好之后，它能明显加快开发速度，减少返工和线上出问题的可能性。

围绕 Agent 友好的端到端测试，他主要做了四件事：

1. 让 Agent 熟悉环境：支持一键启动测试环境、创建测试数据，明确当前版本、测试账号和权限，并提供清理与重置能力。
2. 让 Agent 能操作业务系统：通过浏览器、API 或 CLI，执行真实的业务流程。
3. 让 Agent 方便地查库表和日志：通过只读数据库 MCP 确认落库结果，通过日志系统 Skill 和 Trace 查询链路状态、定位问题。
4. 把繁琐但稳定的流程复用起来：把稳定操作写成脚本，把入口和排障方法整理成 Skill，减少重复的人工介入和对话。

在这个基础上，他还分享了几个目前觉得比较有效的做法：

做法	具体内容
浏览器自动化	业务系统需要浏览器操作时，他推荐 ego lite 这个开源浏览器，方便、速度快。搭配 pi agent + DeepSeek V4 Flash，可以比较快地跑完测试
把操作统一封装成 CLI	把可复用的 Skill、配置好的 MCP 和写好的脚本整合到统一的测试 CLI 中，提供环境检查、数据准备、场景执行、结果查询和清理等能力。这本身也能成为内部提效工具，平时排障很方便
让工具直接服务于验收	DB 查询用于确认状态，日志和 Trace 用于解释失败，但预期结果仍然必须来自业务契约。不能让 Agent 看到系统返回了什么，就认为什么是正确的
产品本身是 Agent 时，还要检查答案质量	如果被测产品本身就是 Agent，除了业务流程是否跑通，还要考虑答案质量，也就是常说的 Agent Eval（原文未展开）

原文给这一条的总结是：在复杂业务逻辑下，系统完全可能返回一个看似合理、实际上不符合需求的结果。工具帮助我们获取证据，而不是替我们定义正确答案。

七、怎么 Review AI 写的代码

前面讲的是怎么让 AI 写出高质量的代码。但作者强调，业务需求的第一责任人仍然是开发者。如果不做 Review，在大型系统里很容易出问题——他也不希望半夜被叫起来 On-call，最后发现是 AI 写的代码出了问题。

针对 Review，他目前主要有四条实践：

1. 先看验收标准，再看测试结果。 先检查 Agent 给出的验收标准，再对照端到端测试的结果，确认是否符合预期、有没有遗漏。不能只看测试通过了多少，还要看这些测试是否验证了这次需求真正关心的事情。
2. 沿着业务路径看实现，把精力放在高风险部分。 他会重点检查权限、状态变化、并发、重试、数据一致性，以及迁移和回滚等高风险部分。对于一些模式稳定的 CRUD，可以少花时间——这部分他现在甚至已经不看了。
3. 专门检查新增的抽象和机制。 对新增的抽象和机制，他会用奥卡姆剃刀这样的思路，让 AI 再帮他审查一遍：它们是否真的有必要，有没有更简单的实现，是否为了局部问题引入了过多复杂度。
4. MR 较多时，考虑构建专门的 Review Bot。 如果组内 MR 比较多，可以设计一个专门的 Review Bot 承担交叉审查。它和前面直接调用 pi agent / Claude Code 做对抗性审查不同，更强调把 Git 中的变更信息和预先设计好的审查流程结合起来，形成一套可以重复执行、专门服务于 MR 的审查能力。

八、总结与思考

瓶颈是 Review 的速度。 作者说自己目前开发最明显的瓶颈就在这里：Agent 可以同时推进好几个任务，但他理解业务、判断方案和确认交付的速度并不会跟着成倍增加。如果只是让它写得更多，最后很可能只是积压了更多等待审查的代码。

所以他想改进的方向是：让重复问题在交到他手里之前，就被发现和修复。 能通过类型检查、测试和业务断言发现的问题，尽量让 Agent 在开发过程中自己处理；需要他判断的，则集中到需求有没有理解对、关键业务逻辑是否成立，以及这次改动还有哪些没有验证的风险。Review Bot 的价值要看能否减少有效问题的遗漏和人工负担，不能只看它评论了多少条。

**关于 Harness：**他说自己对 Harness 的理解逐渐具体起来：除了给 Agent 正确的上下文，还需要给它能执行任务的环境，以及判断结果的依据。他把日常自测里反复做的操作整理成 CLI、脚本和 Skill，让它可以自己运行系统、检查结果、找到失败证据；以后遇到同类任务这些能力能继续使用，也可以逐步交给其他同学复用。

工作流需要定期做减法。 有些步骤是在弥补某一代模型的短板，模型变了就应该重新判断这些步骤是否还有收益。简单任务直接做，复杂任务再增加规划、拆分和交叉审查。他自己的例子是：Astra 更新之后，他删除了 AGENTS.md 中一些过于严格的约束。

验收标准仍然得由人给出。 测试和 Review 能降低不确定性，但正确的验收标准还是得人来定。即使代码和测试互相对得上，也可能是它们一起误解了需求。端到端测试覆盖的，也只是选定环境和场景中的行为；生产环境里的流量、并发和数据分布，仍然可能带来新的问题。

关于踩坑。 作者说自己刚工作不久，很希望在工作中学到更多领域内的专业知识，但 AI 也确实减少了一部分亲自踩坑的机会。有些原本需要经历问题、排查原因才能获得的经验，现在可能变成了 AI 的一句「我错了，现在修改一下」。所以他现在会从每天的开发时间里留出一部分用来学习和复盘，同时思考：在 AI 时代，研发同学真正需要的能力是什么。

想跟着做：从哪里起步

作者给的建议是先挑一条平时最常做的自测路径，试着让 Agent 独立跑通、保留证据，再把有效步骤沉淀下来。对应到具体动作，可以拆成这几步：

1. 挑一条你重复做过三次以上的自测流程（比如某个接口从改完到上线前的验证路径）。
2. 让它能被一键触发：把环境启动、数据准备、账号权限、清理重置都写清楚。
3. 把查询手段接进来：只读数据库 MCP 看落库结果，日志 / Trace 看链路和失败原因。
4. 把稳定操作写成脚本或 Skill，最后收进一个统一的 CLI。
5. 用一条业务契约当验收标准——不是「系统返回了什么」，而是「需求要求什么」。

⚠️ 两点提醒：作者的这套做法是他在自己业务里逐步摸索出来的，适用范围和不足他自己也还在探索；另外，出于公司保密要求，很多细节没法在文章里展开，所以文中的 Skill 名、CLI 结构和环境搭建方式都是方法论层面的参考，落到你的团队里需要按实际情况调整。