你精心搭的AI Skill工作流，新模型下正变成噪声
背景
起因是和组里老板进行了几次 one-on-one。他对我目前使用 AI 工具、搭建个人 Harness，以及 AI Coding 的工作流很感兴趣。主要也是因为，我现在的需求做得又快又好，已经是一些项目的主 O 了。因此，我也借这个机会，整理了一下自己的日常 AI 工作流。目前，我在组里主要做 Agent 开发，同时维护已有的后端业务。
之前，我在小红书里分享过相关的工作流。当时的背景是，GPT-5.4 和 Opus 4.6 已经能在获得准确上下文和合理约束的情况下，很好地完成任务。Harness Engineering 的兴起，也让大家意识到：可以通过增加约束，更好地驾驭强大的模型。
比如 Superpowers 这类 Skill，就提供了一套比较重的实现，主要围绕 Spec 和 TDD，帮助大家更容易地组织和推进任务。
但这么做也有一些弊端。最明显的感受就是：Token 消耗得很快。像 Superpowers 这样的 Skill，包含很多用于约束模型下一步行动的 Workflow。哪怕从全局来看，某个步骤已经没有必要了，比如上下文已经足够，可以直接开始实现，模型仍然可能沿着既定流程继续执行。
随着新模型的发布，我也看到不少开发者开始分享：自己已经基本不用这些很重的 Skill 了。一个主要原因是，模型能力增强之后，一些原本被我们认为有用的约束和流程，正在变成模型的噪声。比如，OpenAI 在发布 Astra 时，还专门写了一篇博客，介绍如何清理不必要的 Skill 和系统提示词，以改善模型的使用体验。
所以，这篇文章会结合我这几个月的实践，分享一些目前对我比较有效的做法，聊聊怎样更好地使用各类 Agent，提高日常开发效率。
一、我常用的 Skill 和 Prompt
我目前的工具分工
目前，我主要用 Codex + GPT-5.6 Sol 做编码实现，用 Astra 做规划。在 Astra 发布之前，规划工作主要交给 GPT-5.6 Sol Max。
简单的需求，我会用 pi + DeepSeek V4 Flash 来实现；方案的对抗性审查和 Code Review，则主要交给 Claude 5 Fable。个人项目中，我还会用网页端 GPT-6 Pro 做主要的方案设计。
我常用的 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
我现在已经很少自己写大段 Prompt 了。有需要时，通常会让 Codex 帮我整理。比如，经过多轮讨论后，我想把当前上下文交给 GPT Pro 做方案设计，就会让 Codex 先生成一份完整的交接 Prompt。
除此之外，我经常使用下面几类很短的 Prompt。
它们有时能起到“一句话顶几千句话”的效果。我把它们理解成模型的“思维快捷键”。
它们不是魔法咒语，而是一些已经在人类知识中高度标准化的方法论。模型在训练过程中见过大量相关论文、代码、设计文档和讨论，所以很多时候，不需要再手写几百行 Workflow，只需要告诉它采用哪套思考方式。下面这些是我自己实践出来非常好用的 prompt：
第一性原理：不要沿着现有方案继续优化，重新问这个问题到底该怎么解。比如，一个接口很慢，你可以这样说：
> 不要基于“加 Redis 缓存”这个既定方案继续设计。从第一性原理分析这个接口为什么慢，以及最小必要的解决方案。
模型的关注点，就会从“Redis 应该怎么设计”，切换成：
> 瓶颈到底在 SQL、网络、序列化、锁竞争，还是重复计算？如果给 SQL 加一个索引就能解决，为什么还要引入 Redis？
这类 Prompt 很适合用在你怀疑“题目本身可能就问错了”的时候。
对抗性审查：不要帮我的方案找理由，想办法证明它是错的
普通的问法是：
> 帮我看看这个技术方案有没有问题。
可以换成：
> 对这个方案做一次对抗性审查，优先寻找能推翻核心假设的反例。
假设你的方案是“为了解决重复请求，引入分布式锁”，模型就不再只是告诉你锁的超时时间应该怎么设置，而是开始追问：
> 重复请求真的需要互斥吗？接口幂等能不能解决？锁服务挂了怎么办？锁过期了，但业务还没执行完怎么办？是不是为了解决一个局部问题，又引入了新的分布式故障点？
这类 Prompt 特别适合方案评审和 Code Review。
消融实验：系统变好了，不代表你加的每一个东西都有用
比如，你一次做了三个优化：
> 加索引、Redis 缓存和批量查询后，接口耗时从 800ms 降到了 100ms。
这时候可以直接问：
> 给这三个优化设计消融实验，判断真正的收益来自哪里。
模型就会围绕不同组合设计对照，比如以 Baseline 为起点，比较只加索引、索引 + 缓存、索引 + 缓存 + 批量查询等组合。
最后可能发现：
> 只加索引，就已经把耗时从 800ms 降到了 120ms，剩下两个复杂方案只贡献了 20ms。
这样，你就更清楚哪些代码值得保留，哪些复杂度可能没有必要。
奥卡姆剃刀：效果差不多时，优先选择假设更少、复杂度更低的方案
比如，Agent 给你设计出这样一套方案：
> Kafka + Redis + 分布式锁 + 状态机 + 定时补偿。
你可以补一句：
> 用奥卡姆剃刀重新审查这个设计，在满足需求的前提下，删除所有非必要机制。
很多时候，它最后会发现：
> 当前场景只有单库写入，一个事务加唯一索引就够了。
这句话对现在的 Coding Agent 尤其有用，因为模型很容易为了“完整”而过度设计。
高内聚、低耦合：重新检查代码的职责和边界
比如，你发现一个 OrderService 已经有 2000 行，可以这样问：
> 按高内聚、低耦合原则审查 OrderService 的职责边界，不要为了拆而拆。
模型通常会开始检查：
> 为什么订单服务同时负责库存、优惠券、短信、支付和报表？哪些逻辑属于订单领域本身，哪些应该通过稳定接口交给其他模块？
它激活的不是简单的“拆文件”，而是一整套关于模块化、信息隐藏、依赖方向和职责划分的判断。
所以，我现在很少再写：
> 第一步分析需求，第二步检查假设，第三步寻找替代方案，第四步……
很多成熟的方法论，模型本身已经学过。我更倾向于直接告诉它：
> 从第一性原理重新分析，对当前方案做对抗性审查；核心机制必须通过消融实验验证；方案遵循奥卡姆剃刀，代码保持高内聚、低耦合。
这几十个字背后，实际上指定了五种不同的认知动作：
> 重新定义问题 → 攻击假设 → 验证贡献 → 删除复杂度 → 整理系统边界。
这也是我理解的新模型时代 Prompt Engineering 的一个变化：与其给模型写死一套完整的思考流程，不如用准确的方法论告诉它“应该以什么方式思考”，再补充当前任务真正必要的约束。
二、我的日常开发工作流
拿到一个需求后，我通常会先把相关上下文交给 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。
这件事前期确实需要花一些功夫，但不要怕麻烦。搭建好之后，它能明显加快开发速度，减少返工和线上出问题的可能性，自己也不用整天担心 AI 写的代码会不会出事故。
围绕 Agent 友好的端到端测试，我主要做了四件事：
让 Agent 熟悉环境：比如，支持一键启动测试环境、创建测试数据，明确当前版本、测试账号和权限，并提供清理与重置能力。
让 Agent 能操作业务系统：通过浏览器、API 或 CLI，执行真实的业务流程。
让 Agent 方便地查库表和日志：通过只读数据库 MCP 确认落库结果，通过日志系统 Skill 和 Trace 查询链路状态、定位问题。
把繁琐但稳定的流程复用起来：把稳定操作写成脚本，把入口和排障方法整理成 Skill，减少重复的人工介入和对话。
在这些工作的基础上，再分享几个我目前觉得比较有效的做法。
浏览器自动化：业务系统需要浏览器操作时，我比较推荐 ego lite 这个开源浏览器。用起来很方便，速度也快。搭配 pi agent + DeepSeek V4 Flash，可以比较快地跑完测试，减少测试耗时。
把操作统一封装成 CLI：把可复用的 Skill、配置好的 MCP 和写好的脚本，整合到统一的测试 CLI 中，提供环境检查、数据准备、场景执行、结果查询和清理等能力。这其实也可以成为一个内部提效工具。目前，我已经把这套东西做成了 CLI，平时遇到问题，用它排障也很方便。
让工具直接服务于验收：DB 查询用于确认状态，日志和 Trace 用于解释失败，但预期结果仍然必须来自业务契约，不能让 Agent 看到系统返回了什么，就认为什么是正确的。在复杂业务逻辑下，系统完全可能返回一个看似合理、实际上不符合需求的结果。工具帮助我们获取证据，而不是替我们定义正确答案。
产品本身是 Agent 时，还要检查答案质量：如果被测试的产品本身就是 Agent，除了业务流程是否跑通，还需要考虑答案质量。这也就是我们经常说的 Agent Eval，这里就不详细展开了。
四、怎么 Review AI 写的代码
前面分享了怎么让 AI 写出高质量的代码，但最终，业务需求的第一责任人仍然是开发者。
如果不做 Review，在大型系统里很容易出问题。
你也不希望半夜被叫起来 On-call，最后发现是 AI 写的代码出了问题吧。
针对 Review，我目前主要有下面几条实践。
先看验收标准，再看测试结果：先检查 Agent 给出的验收标准，再对照前面端到端测试的结果，确认是否符合预期、有没有遗漏。不能只看测试通过了多少，还要看这些测试是否验证了这次需求真正关心的事情。
沿着业务路径看实现，把精力放在高风险部分：我会重点检查权限、状态变化、并发、重试、数据一致性，以及迁移和回滚等高风险部分。对于一些模式稳定的 CRUD，可以少花一些时间——这部分甚至我现在已经不看了。
专门检查新增的抽象和机制：对新增的抽象和机制，我会用奥卡姆剃刀这样的思路，让 AI 再帮我审查一遍：它们是否真的有必要，有没有更简单的实现，是否为了局部问题引入了过多复杂度。
MR 较多时，考虑构建专门的 Review Bot：如果组内 MR 比较多，可以设计一个专门的 Review Bot，承担交叉审查。它和前面直接调用 pi agent / Claude Code 做对抗性审查不同，更强调把 Git 中的变更信息和预先设计好的审查流程结合起来，形成一套可以重复执行、专门服务于 MR 的审查能力。
五、一些总结和思考
我目前开发最明显的瓶颈，是 Review 的速度。
Agent 可以同时推进好几个任务，但我理解业务、判断方案和确认交付的速度，并不会跟着成倍增加。如果只是让它写得更多，最后很可能只是积压了更多等待审查的代码。
所以，我接下来想改进的，是让重复问题在交到我手里之前，就被发现和修复。
能通过类型检查、测试和业务断言发现的问题，尽量让 Agent 在开发过程中自己处理；需要我判断的，则集中到需求有没有理解对、关键业务逻辑是否成立，以及这次改动还有哪些没有验证的风险。
专门的 Review Bot 可以帮助做这些事，但它的价值，要看能否减少有效问题的遗漏和人工负担，不能只看它评论了多少条。
这也让我对 Harness 的理解逐渐具体起来：除了给 Agent 正确的上下文，还需要给它能执行任务的环境，以及判断结果的依据。
我把日常自测里反复做的操作整理成 CLI、脚本和 Skill，让它可以自己运行系统、检查结果、找到失败证据。以后遇到同类任务，这些能力就能继续使用，也可以逐步交给其他同学复用。
与此同时，这套工作流也需要定期做减法。
有些步骤是在弥补某一代模型的短板。模型变了，就应该重新判断这些步骤是否还有收益。简单任务直接做，复杂任务再增加规划、拆分和交叉审查。比如 Astra 更新之后，我就删除了 AGENTS.md 中一些过于严格的约束。模型在迭代，我们的工作流也需要跟着迭代。
当然，测试和 Review 能降低不确定性，但仍然需要人给出正确的验收标准。即使代码和测试互相对得上，也可能是它们一起误解了需求。端到端测试覆盖的，也只是选定环境和场景中的行为；生产环境里的流量、并发和数据分布，仍然可能带来新的问题。
对我这样刚工作不久的开发者来说，我还是很希望在工作中学到更多领域内的专业知识。不过，AI 也确实减少了一部分亲自踩坑的机会。有些原本需要经历问题、排查原因才能获得的宝贵经验，现在可能变成了 AI 的一句：
> “我错了，现在修改一下。”
所以，
我现在也会从每天的开发时间里留出一部分，用来学习和复盘，同时思考：在 AI 时代，研发同学真正需要的能力是什么。
这篇文章记录的，是我入职这几个月，在自己的业务里逐渐摸索出来的一套做法。它的适用范围和不足，我也还在探索。
大家可以先挑一条平时最常做的自测路径，试着让 Agent 独立跑通、保留证据，再把有效步骤沉淀下来。
出于公司保密要求，很多细节没办法在文章里展开。希望这篇文章能抛砖引玉，也很想听听大家在实际开发中的好做法～