先把结论放前面。
模型变强之后，真正该做的是减法。你给 Agent 加的那些约束和流程，很多只是在补上一代模型的短板。
起因是和王老板的一次 one-on-one。他对我用 AI 工具、搭个人 Harness、整套 AI Coding 工作流挺感兴趣。
我把这几个月的做法整理成 8 条。每条都能直接抄，其中好几条是我踩过坑才写下来的。
8 条 AI Coding 硬经验
先交代一个背景，不然这几条会显得没来由。
之前我分享过一版工作流。那会儿 GPT-5.4 和 Opus 4.6 已经能在拿到准确上下文、给出合理约束的前提下把事做好。Harness Engineering 也是那时候热起来的，大家的共识是靠增加约束去驾驭更强的模型。
Superpowers 就是比较典型的一类，围绕 Spec 和 TDD 给了一整套挺重的实现。用下来最直接的感受是，Token 烧得飞快。
它里面有大量 Workflow 约束模型的下一步动作。哪怕从全局看某一步已经没必要了，上下文已经够、可以直接动手，模型还是可能沿着既定流程往下走。
新模型一发布，我也看到不少开发者在分享，说自己基本不用那些很重的 Skill 了。
原因挺直接。模型能力上来之后，一些原本有用的约束和流程，正在变成噪声。
下面这 8 条，就是我在这个前提下摸索出来的。
全文总览，8 条可以单独收藏
逐条说。
01先做减法，再做加法
判断一个东西还有没有用，不看它当初多有道理，只看它现在还在不在干活。
我给 Agent 配的东西，和给系统配的东西，清理逻辑是一样的。前阵子 OpenClaw 频繁崩溃、延迟严重，我扒了启动日志，根因指向一个我从没用过的 Matrix 渠道扩展。
它依赖的原生加密模块没装上，Node 进程一启动就直接退出。如果配了进程守护，它会不停重启；这种崩溃—重启的死循环，把 CPU 吃满，延迟就是被这么拖出来的。
我没有去给崩溃加监控，也没有去调超时参数。我做的事只有一件——把这个扩展禁用。
案例 一个从没用过的扩展，缺一个原生模块，就能让整个 Agent 平台起不来，还顺带拖慢所有请求。把它从配置里删掉之后，崩溃消失，延迟也跟着回落了。删掉一个从不干活的模块，比给崩溃加十层监控都管用。
这条的顺序很重要。先减，再加。反过来做，你只会一直往上摞。
02指定思考方式，别写死流程
那些方法论模型早就学过，你只需要告诉它这次用哪一套。
我已经很少自己写大段 Prompt 了。有需要的时候，让 Codex 帮我整理。
平时我经常用的，是几个很短的 Prompt。我把它们理解成模型的思维快捷键。
它们不是魔法咒语，是一些在人类知识里已经高度标准化的方法论。模型在训练里见过大量相关论文、代码、设计文档和讨论，所以很多时候不用手写几百行 Workflow，只要告诉它用哪一套思考方式。
案例 前阵子飞书开源了 CLI，我把链接丢给 OpenClaw，只说了一句"把这个装上"。它没等我写安装步骤，自己跑完两行命令，把 19 个 Skills 全装好，还自动适配了 Claude Code、OpenClaw、OpenCode 这些主流 Agent 平台。之后扫码授权不到一分钟，多维表格、消息、日历、邮箱、任务全部打通。最后我只说"帮我建个周一上午 10 点的会"，它就建好了。从头到尾，我没描述过一个操作步骤，只说了我要什么。
五个关键词，对应五种认知动作
对照一下。
以前我写的是，第一步分析需求，第二步检查假设，第三步寻找替代方案，第四步……
现在我基本只写一句。
从第一性原理重新分析，对当前方案做对抗性审查，核心机制必须通过消融实验验证，方案遵循奥卡姆剃刀，代码保持高内聚、低耦合。
这几十个字背后，指定了五种认知动作。重新定义问题，攻击假设，验证贡献，删除复杂度，整理系统边界。
后面四条，我把具体用法和案例拆开写。
03对抗性审查
不要让它帮你找理由，让它想办法证明你是错的。
普通问法是，帮我看看这个技术方案有没有问题。可以换成这一句。
对这个方案做一次对抗性审查，优先寻找能推翻核心假设的反例。
案例 抖音自动化跑完 27 个目标，点赞 27 个全成功，评论却 0 个新增，55 个视频全被拦，返回 status:8。我第一反应是"金融内容限流"，因为目标账号清一色是农业、土地、理财、房产。
我拿这句话审了一遍。它反过来咬我的假设：如果真是内容问题，换个非金融博主应该能发；可日志里每条评论只等了 8-15 秒就被限流。正常账号是"发几十条之后"才限流，我们却是"发第一条就直接 status:8"。
结论被推翻了——不是内容类型，是账号已经被判定为机器行为。方向一变，处理方式全变：不是换关键词，而是停号 24-48 小时等限流解除。
这条特别适合方案评审和 Code Review。
04消融实验
系统变好了，不代表你加的每一个东西都有用。
这个是三条方法论里我最常用的一条，因为它直接关系到你最后要留多少代码。
给这几个可疑项设计消融实验，判断真正的收益到底来自哪里。
案例 排查 OpenClaw 延迟时，我列了四个可疑项：Matrix 扩展崩溃重启、多余渠道在轮询、Defender 在扫 Node 的小文件、模型代理走不通。
四个一起改，降了多少也说不清是谁的功劳。所以我先只动一个——修 Matrix。
进程一稳定存活，崩退的死循环没了，延迟的大头跟着就落了下去。剩下三项我留着没急着加，因为 Baseline 一变，它们大概率只是噪声。
四个可疑项里，真正干活的只有一个。
05奥卡姆剃刀
效果差不多的时候，优先选假设更少、复杂度更低的方案。
这句话对现在的 Coding Agent 尤其有用，因为模型很容易为了「完整」而过度设计。
用奥卡姆剃刀重新审查这个设计，在满足需求的前提下，删除所有非必要机制。
案例 抖音获客系统一开始列出来的，是一套完整的商用级架构：Redis 任务队列、多账号池、风控引擎、指纹伪装、大模型话术生成，一次全上。
我让它用奥卡姆剃刀审一遍。它的结论是，这套系统要对抗的是持续更新的风控，一次性全建，大半是还没发生的假设。
最后砍成三期：第一期只留两样——一个用内存队列的调度器，加一个 Playwright 单账号执行器；Redis 换成内存队列，多账号和风控全推到第二期。第一天要跑的，只是"一个号把点赞、评论、私信跑通"。备一套 Redis，不如先把一个号跑稳。
判断标准其实很简单：这个机制是在满足需求，还是在满足想象。前者留，后者删。
06先对齐，再动手
对齐的目标不是把细节规划完，是把问题问到这个程度，剩下的答案已经不会改变方向。
案例 抖音获客工作流开工前，我先把手上的材料丢给 Agent 读。它没急着动手，而是列了一份"还缺什么"：国内社交平台通道层的鉴权方式、反爬策略的处理方案、飞书多维表格和大模型之间的字段表，还有"意向极高"时人工介入的告警机制。
这几条我当场答不全。有的我去翻文档，有的回头找人确认。它还追了一个更靠前的问题——目标是精准获客，那为了绕开限流去评论美食号，粉丝根本不匹配，这套流程本身还成立吗。
等剩下的问题已经不会显著改变实现方向，才动手。结论沉淀成一份 Spec，后面执行的 Agent 直接读，不用重听一遍全过程。
结论沉淀到 Spec 或 CONTEXT.md，记录这次要解决的问题、范围、关键决策和验收标准。后面负责实现和审查的 Agent 共享这一份，不用重新读完全部对话。
我不会要求它把每个实现细节都提前规划好，否则对齐本身又会变成一套很重的流程。
07给 Agent 一个能自己跑的环境
没有端到端环境的 Agent，只能写出「单测全绿」的代码。
AI 已经很擅长写测试了，动不动给一个 Bugfix 写上几百行。多写没问题，但上线之后还是会遇到预期之外的错误。
案例 抖音 Phase 1 我没让它写单测，而是直接接真环境——用 CDP 连上已经登录好的 Chrome，真的去点赞，真的去发评论。
27 个目标跑完，点赞 27 个全成功；评论 0 个新增，55 个视频全被 status:8 拦下。这一层本地模拟永远测不出来——它是账号被判机器行为之后，平台给的真实反馈。
也正因为跑通了真链路，才知道下一步是停号等限流解除，而不是回去改评论文案。
我给业务搭的这套环境，主要四件事。
让 Agent 能进真实环境。提前打开 Chrome 的调试端口，复用已经登录好的账号，脚本本身不碰登录流程；环境要能一键起、能重置。
让它能操作真实系统。用 CDP 接上真实浏览器，不是无头模拟，去页面上真的点赞、真的评论、真的发私信。
让它能查执行结果。每个操作都带时间戳和状态，写进执行报告；单个任务失败不打断整体流程，方便回头定位。
把繁琐但稳定的流程复用起来。把点赞、评论、私信固化成一个 Skill，下次直接对话触发"运行抖音 Phase 1"。
最后收成一个统一入口，一条命令就能跑一个批次，用参数控制数量。现在我自己遇到问题，也习惯先用它排障。
但有一条红线。
工具帮我们拿证据，而不是替我们定义正确答案。
DB 查询用来确认状态，日志和 Trace 用来解释失败，但预期结果仍然必须来自业务契约。
不能让 Agent 看到系统返回了什么，就认为什么是正确的。复杂业务逻辑下，系统完全可能返回一个看似合理、实际不符合需求的结果。
如果被测试的产品本身就是 Agent，除了流程跑通，还要看答案质量，也就是常说的 Agent Eval，这里就不展开了。
08Review 只花在高风险的地方
你不需要逐行读 AI 的代码，你需要读对地方。
业务需求的第一责任人仍然是开发者。不做 Review，在大型系统里很容易出问题。你也不希望半夜被叫起来 On-call，最后发现是 AI 写的代码。
先看验收标准，再对照端到端测试结果。不能只看测试通过了多少，还要看这些测试是不是验证了这次需求真正关心的事。
再沿着业务路径看实现，重点检查权限、状态变化、并发、重试、数据一致性，以及迁移和回滚。模式稳定的 CRUD 少花时间，这部分我甚至已经不看了。
新增的抽象和机制，我会用奥卡姆剃刀的思路让 AI 再审一遍，它是不是真的有必要。
案例 抖音自动化里，我一开始用剪贴板粘贴来发私信，demo 里能跑通。Review 的时候我只问一句：它到底靠什么成立。
答案是三个假设——输入框先拿到焦点、剪贴板没被系统拦、页面没禁用粘贴事件。缺一个，它就静默失败，还不报错。
换成直接写进 DOM、再补一个 input 事件之后，成功率稳定在 95% 以上。反倒是点赞那种模式固定的点击，我基本不逐行看了。这种"看着能跑、其实靠巧合"的机制，才是该停下来审的地方。
这么做的前提，是每次 MR 的范围都足够小。小 MR 让每次需要判断的改动可控，端到端测试帮你确认这些改动放进真实业务流程之后成立。
如果组里 MR 比较多，可以做一个专门的 Review Bot 承担交叉审查。它和直接让模型做对抗性审查不一样，更强调把 Git 里的变更信息和预先设计好的审查流程结合起来，形成一套可以重复执行的审查能力。
它的价值要看能不能减少有效问题的遗漏和人工负担，不能只看它评论了多少条。
— 尾 声 —
最后还有一句
这 8 条里，我最想留下的是第 1 条。
我目前开发最明显的瓶颈，是 Review 的速度。Agent 可以同时推进好几个任务，但我理解业务、判断方案、确认交付的速度，并不会跟着成倍增加。只是让它写得更多，最后很可能只是积压更多等我审的代码。
所以现在我在做的，是让重复问题在交到我手里之前就被发现和修复。能通过类型检查、测试和业务断言发现的问题，交给 Agent 自己处理。需要我判断的，集中到需求有没有理解对、关键业务逻辑是否成立，以及还有哪些没验证的风险。
这也让我对 Harness 的理解慢慢具体起来。除了给 Agent 正确的上下文，还需要给它能执行任务的环境，以及判断结果的依据。
模型在迭代，工作流也得跟着迭代。有些步骤只是在补某一代模型的短板，模型变了就该重新判断它还有没有收益。简单任务直接做，复杂任务再加规划和交叉审查。
当然，测试和 Review 能降低不确定性，但仍然需要人给出正确的验收标准。即使代码和测试互相对得上，也可能是它们一起误解了需求。
对我这样刚工作不久的开发者来说，我还是很想在工作里学到更多领域内的专业知识。不过 AI 也确实减少了一部分亲自踩坑的机会。有些原本要经历问题、排查原因才能得到的经验，现在变成了一句。
「我错了，现在修改一下。」
所以我现在会从每天的开发时间里留出一部分，用来学习和复盘，同时想一想，在 AI 时代，研发同学真正需要的能力到底是什么。
这 8 条来自我个人的业务，适用范围和不足我也还在探索。大家可以先挑一条平时最常做的自测路径，试着让 Agent 独立跑通、保留证据，再把有效步骤沉淀下来。
出于保密要求，很多细节没法展开。希望这篇能抛砖引玉，也很想听听大家在实际开发里的好方法。