1. 从“能跑通”到“跑得漂亮”为什么代码之外的判断力才是分水岭写代码这件事门槛正在肉眼可见地塌陷。几年前我们还在争论“低代码到底能不能替代程序员”现在这个问题已经没什么人讨论了因为真正的问题变成了另一个当生成一段可运行代码的成本趋近于零时一个开发者、一个产品团队、一个内容创作者凭什么还能拉开差距我最近反复在琢磨一个词——品味。不是审美意义上的那种“好看”而是一种更底层的判断力面对十个都能跑通的方案你知道哪个是对的面对一堆功能都实现了的界面你知道哪个让人用起来舒服面对一段逻辑正确的代码你知道它三个月后会不会变成维护噩梦。这种判断力我把它叫做“超越代码”的部分。这个项目标题里提到的“超级智能AI代理”说白了就是那些能自主规划、调用工具、多步推理、甚至自我纠错的AI系统。它们确实越来越强强到可以帮你写完整模块、生成测试用例、重构遗留代码。但越是这种时候我越发现一个反直觉的现象工具越强使用工具的人的品味就越重要。因为工具能帮你把“做出来”这件事变得极其廉价但“做对”这件事依然需要人来拍板。这篇文章我想聊的就是这个。适合谁来读如果你是一个正在深度使用AI代理写代码的开发者或者是一个带团队做产品的技术负责人又或者是一个靠AI辅助做内容创作的人那这些经验对你应该有用。我会从方案选型、代理协作、实操流程、踩坑排查几个角度把“品味”这个听起来很虚的东西拆成能落地、能复现的具体动作。2. 核心思路拆解AI代理时代什么该交给机器什么必须自己扛2.1 先搞清楚“超级智能AI代理”到底强在哪、弱在哪很多人对AI代理的想象还停留在“我说一句它写一段”的阶段。实际上现在的代理系统已经能做到接收一个高层目标自己拆解成子任务调用搜索、读写文件、执行命令、调用API根据中间结果调整策略最后交付一个相对完整的结果。这个能力链条里规划、执行、纠错三个环节是核心。但它的弱点同样明显。我实测下来代理在以下几种场景里特别容易翻车目标模糊时你给的需求越笼统它越容易朝着一个“看起来合理但实际跑偏”的方向狂奔而且跑得越远纠偏成本越高。多方案权衡时它倾向于选“最常见”的方案而不是“最适合当前上下文”的方案。比如你让它选一个状态管理库它可能默认给你上最流行的那个完全不考虑你项目只有三个页面。边界条件处理时正常路径它能写得漂漂亮亮但异常分支、并发冲突、数据一致性这些地方它经常给出“理论上可行但工程上危险”的代码。所以我的核心思路是把代理当成一个执行力极强但判断力需要校准的初级工程师。规划的大方向、方案的取舍、边界的定义这些必须由人来把控具体的实现、重复的搬运、格式的转换大胆交给它。2.2 为什么“品味”不能被提示词完全替代有人会说那我把品味写成提示词不就行了比如“请选择最简洁的方案”“请考虑可维护性”。我试过效果有限。原因在于品味本质上是一种上下文敏感的权衡能力它依赖于你对当前项目阶段、团队能力、业务压力的综合判断而这些信息很难被完整地塞进一段提示词里。举个例子。同样一个功能创业公司三个月要上线和一家成熟公司做一个内部工具最优解可能完全不同。前者要的是“最快能跑、后面再重构”后者要的是“一次写对、少留技术债”。代理不知道你处在哪个阶段它只能按通用最优来。这个“按什么标准来最优”的判断就是品味。再往深一层说品味还体现在对“不做什么”的克制上。代理倾向于把所有能加的功能都加上把所有能写的抽象都写出来。但真正有经验的开发者知道很多抽象是过早的很多功能是不该做的。这种“减法”的判断目前只能靠人。2.3 一个可复用的协作框架人定标准代理执行人做验收基于上面的分析我摸索出一套还算顺手的协作框架分三步人定标准在让代理动手之前我先用几句话把“什么算好”定义清楚。比如“这个模块的对外接口不超过五个方法”“所有错误必须被显式处理不允许吞异常”“新增依赖必须说明理由”。这些标准不需要多但必须具体。代理执行把标准连同任务一起交给代理让它在一个有约束的空间里发挥。约束越清晰它的输出越稳定。人做验收代理交付后我不看它写了多少行而是对照最初的标准逐条检查。不符合的要么让它改要么自己动手改。这个验收环节是品味真正发挥作用的地方。这套框架的好处是它把人的精力从“写”转移到了“判断”上而判断恰恰是人比机器强的地方。下面我会把这套框架拆成更细的实操步骤。3. 核心细节解析把“品味”拆成可执行的检查项3.1 方案选型时的三个灵魂拷问每次代理给出一个方案或者我自己面对多个选择时我会问三个问题。这三个问题帮我过滤掉了大量“看起来不错但实际会后悔”的决定。第一个问题这个方案在最坏情况下会怎样代理通常展示的是正常路径但工程里大部分痛苦来自异常路径。比如它建议用一个内存缓存来加速查询正常情况确实快但如果缓存和数据库不一致了怎么办如果进程重启缓存全丢了怎么办把这些最坏情况想一遍很多花哨的方案就自动出局了。第二个问题三个月后一个不熟悉这个代码的人能看懂吗代理写的代码有时候很“聪明”用了各种语言特性和设计模式但聪明不等于好维护。我倾向于选择那些“笨但清晰”的方案哪怕多写几行。因为维护成本的大头不是写的时候而是读的时候。第三个问题这个决定可逆吗有些决定一旦做了后面改起来伤筋动骨比如数据库选型、核心架构分层。这种决定我会花大量时间反复权衡。而有些决定改起来很容易比如某个工具函数怎么写、某个配置放哪里。对于可逆的决定快速拍板让代理去执行对于不可逆的决定慢下来自己扛。3.2 代理协作中的“约束设计”技巧给代理下任务最忌讳的是“你看着办”。我的经验是约束要像给初级工程师写任务卡一样具体到可验证。比如我要让代理帮我重构一个模块我不会说“把这个模块重构一下”。我会说重构后对外暴露的函数不超过三个所有数据库操作必须通过已有的仓储层不允许直接调用每个函数不超过四十行不允许新增第三方依赖重构后原有测试必须全部通过这些约束里前四条是“品味”的体现最后一条是“正确性”的底线。代理在这五条约束下工作输出质量会稳定很多。而且这些约束本身也是我验收时的检查清单一举两得。还有一个技巧是分阶段交付。不要让代理一次性完成一个大任务而是让它先出一个方案大纲我确认后再让它写具体实现实现完再让它自己写测试。每个阶段我都有机会介入和纠偏。这比一次性拿到一大坨代码再回头改要高效得多。3.3 验收环节的“三看”原则代理交付后我的验收分三步一看结构文件组织是否合理模块边界是否清晰有没有出现“一个文件干所有事”的情况。结构不对后面全白搭。二看异常把所有错误处理路径过一遍。代理最容易在这里偷懒比如用空的catch块、用默认值掩盖错误、或者干脆不处理。我会特别关注那些“理论上不会发生”的分支因为线上事故往往就出在那里。三看命名变量名、函数名、类名是否准确表达了意图。命名是代码可读性的第一道关也是代理经常敷衍的地方。如果我发现一个函数叫handleData我会让它改成能说清楚“处理什么数据、怎么处理”的名字。这三看下来基本能过滤掉大部分质量问题。剩下的细节比如性能优化、边界微调可以后面慢慢来。4. 实操过程一个完整的代理协作案例拆解4.1 场景设定与目标定义假设我要做一个内部用的数据看板需求是从几个数据源拉取指标做简单聚合然后在一个网页上展示。团队只有我一个人时间预算两天。这个场景很典型需求不复杂但涉及多个环节数据获取、处理、展示而且我对“好”的定义很明确——能快速上线、后面好改、不引入不必要的复杂度。基于这个定义我先定了几条标准不引入前端框架用原生HTML加少量JS数据处理逻辑独立成一个模块方便后面替换数据源所有配置项集中在一个文件里不引入数据库数据直接内存处理这些标准定完其实方案已经收敛了大半。代理要做的是在这个框架里填充具体实现。4.2 分阶段下发给代理的任务清单我把整个任务拆成四轮对话第一轮方案确认。我把需求和标准发给代理让它先出一个技术方案包括文件结构、每个文件的职责、关键函数的签名。它给了一个方案我调整了两处一是它想用一个轻量模板引擎我砍掉了直接用字符串拼接二是它想把数据获取和处理混在一个文件里我要求拆开。第二轮核心逻辑实现。我让代理实现数据处理模块约束是输入是原始数据数组输出是聚合后的对象所有异常必须抛出不允许返回默认值函数不超过三十行。它写完后我检查了异常处理和命名改了两个变量名。第三轮展示层实现。让代理写HTML和JS约束是不依赖任何外部库数据通过一个全局函数获取页面加载后自动刷新一次。这部分它做得不错我只调整了样式细节。第四轮测试与文档。让代理为数据处理模块写单元测试覆盖正常路径和三种异常情况。然后写一个简短的README说明怎么配置数据源、怎么启动。四轮下来总共花了大概三个小时其中我花在“定标准”和“验收”上的时间占了一大半真正让代理写代码的时间反而不多。但最终交付的质量比我以前自己从头写要稳定得多。4.3 关键参数与配置的取舍记录这个案例里有几个取舍值得记录为什么不用前端框架因为页面只有一个交互只有刷新。引入框架带来的构建配置、依赖管理、学习成本远超它带来的便利。代理一开始建议用某个流行框架我否掉了。这个判断就是品味——知道什么时候不用重型工具。为什么数据处理要独立成模块因为数据源后面大概率会变。今天从A拉明天可能从B拉。把处理逻辑独立出来换数据源时只需要改获取部分处理逻辑不动。这个判断也是品味——为未来的变化留出接缝但不为想象中的变化过度设计。为什么配置集中在一个文件因为部署的时候只需要改一个地方。分散的配置是运维噩梦这个教训我踩过太多次。这些取舍代理不会主动帮你做因为它不知道你的部署环境、团队习惯、未来规划。这些信息在你脑子里你得自己判断然后把判断结果作为约束传给代理。5. 常见问题与排查技巧实录5.1 代理“跑偏”了怎么办代理跑偏的典型表现是你让它改A它顺手把B也改了你让它实现一个函数它给你重构了整个文件。遇到这种情况我的处理方式是立即停止不要让它继续往下写。跑偏的代码越多回滚成本越高。回退到上一个正确状态然后重新下发任务这次把约束写得更死。比如加上“只修改这个文件”“不要动其他任何文件”“不要重命名现有函数”。如果反复跑偏说明任务粒度还是太大继续拆。拆到它一次只能做一件小事为止。我踩过的一个坑是有一次让代理优化一个查询它把整个数据访问层重写了。虽然新代码确实更快但引入了两个新依赖而且原来的测试挂了一半。回滚花的时间比重新写还多。从那以后我给代理的任务卡上永远有一条改动范围不超过我指定的文件。5.2 代理写的代码“能跑但难看”怎么处理这种情况太常见了。代码逻辑没问题测试也过但读起来别扭命名随意、嵌套过深、重复代码多。我的处理分两种情况如果这段代码是临时的、一次性的我忍了不花时间改。品味要用在刀刃上不是所有代码都值得打磨。如果这段代码是要长期维护的我会让代理自己改。具体做法是把我觉得难看的地方指出来告诉它“这里命名不清晰”“这里嵌套太深”让它重写。通常它能改好因为“难看”这件事指出来之后它是有能力修正的。但如果改了两轮还不行我就自己动手。跟代理较劲的时间成本有时候比自己写还高。5.3 如何判断一个代理是否“值得用”不是所有代理都值得投入时间。我判断的标准很简单看它在约束下的表现。给它一个明确的任务和几条清晰的约束看它能不能在不违反约束的前提下完成任务。如果能说明它值得培养如果它总是“自作主张”突破约束或者需要你反复提醒同样的要求那它可能不适合你的工作流。还有一个观察点是纠错能力。你指出一个错误后它是只改这一处还是能举一反三检查同类问题后者说明它有“理解”而不只是“匹配”。这个能力在长期协作中非常关键。5.4 常见问题速查表问题现象可能原因处理方式代理改动范围超出预期任务约束不够具体明确指定可修改的文件和函数代码能跑但异常处理缺失代理倾向走正常路径验收时专门检查所有catch和错误分支命名随意、可读性差代理缺乏项目上下文提供命名规范或让它参考现有代码风格反复犯同一个错误约束没有形成检查清单把要求写成可验证的条目每次验收对照方案过于复杂代理倾向“通用最优”明确项目阶段和约束条件砍掉不必要抽象测试覆盖不足代理默认只测正常路径要求覆盖至少三种异常情况6. 影响范围分析这套方法适合谁、不适合谁6.1 最适合的场景个人开发者与小团队快速交付这套“人定标准、代理执行、人做验收”的方法在个人开发者和小团队里效果最明显。因为这种场景下决策链条短标准容易统一代理的输出能直接被验收和使用。我自己用这套方法做过几个内部工具从想法到可用版本基本都在一天以内而且后面改起来不痛苦。另一个适合的场景是原型验证。当你需要快速验证一个想法时让代理把架子搭起来你专注于核心逻辑和关键判断能省下大量时间。原型阶段对代码质量的要求可以放宽品味主要体现在“快速验证核心假设”上而不是“写出漂亮代码”。6.2 需要谨慎的场景大型遗留系统与强合规环境如果你的项目是一个跑了多年的大型系统或者处在强合规、强审计的环境里那这套方法要谨慎使用。原因在于代理对遗留系统的上下文理解几乎为零它给出的方案很可能与现有架构冲突或者违反某些隐性的约定。这种场景下代理更适合做局部辅助比如写测试、生成文档、做代码审查的初筛而不是直接改核心逻辑。强合规环境还有一层问题代理生成的代码责任归属不清晰。如果出了问题是写提示词的人负责还是验收的人负责这个在流程上需要提前想清楚。6.3 对开发者能力结构的影响往大了说这套协作方式正在改变开发者的能力结构。以前我们强调“写得快、写得多”现在“写得快”这件事正在被代理接管真正稀缺的是判断力判断什么该做、什么不该做、什么现在做、什么以后做。这意味着如果你还在靠“熟练度”吃饭压力会越来越大。但如果你有意识地在日常工作中训练自己的品味——每次做决定时多问一句“为什么选这个不选那个”——那你的价值反而会放大。因为代理再强它也需要一个人来告诉它“什么算好”。我个人的体会是自从开始用代理协作我花在“想”上的时间明显变多了花在“敲”上的时间变少了。这个转变一开始不太适应但慢慢发现想清楚之后再动手返工率低了很多。这可能就是标题里说的“超越代码”的意思——代码本身越来越不值钱代码背后的判断越来越值钱。7. 我踩过的坑与几条实在建议7.1 不要用代理来逃避思考这是我最想分享的一条。代理最危险的地方是它让你产生一种“我在干活”的错觉。你不停地发指令、收结果、再发指令看起来很忙但实际上你只是在做搬运没有在做判断。时间长了你的判断力会退化。我的做法是每天留出一段时间关掉代理自己写一点代码或者至少自己读一点代码。保持手感也保持判断的敏锐度。代理是工具不是拐杖。7.2 标准要写下来不要留在脑子里我一开始觉得标准这种东西自己心里清楚就行了不用写出来。后来发现写下来有两个好处一是给代理看它的输出会更稳定二是给自己看验收的时候有据可依不会因为“感觉差不多”就放过去。我现在习惯在项目根目录放一个STANDARDS.md里面列着这个项目的几条核心原则。每次让代理干活之前我会把相关条目贴给它。这个习惯帮我省了很多来回沟通的时间。7.3 验收时不要只看“能不能跑”“能跑”是最低标准不是验收标准。我见过太多代码测试全绿但结构混乱、命名随意、异常处理缺失后面改一个小需求就要动五个文件。这种代码的维护成本会在几个月后集中爆发。所以验收的时候我强制自己看三样东西结构、异常、命名。这三样过关了才进入下一轮。这个习惯一开始很累但坚持一段时间后代理的输出质量会明显提升因为它知道你会检查这些。7.4 给代理的约束要“可验证”“代码要清晰”这种约束代理没法执行因为它不知道什么叫清晰。但“函数不超过四十行”“不允许空的catch块”“新增依赖必须说明理由”这些是可验证的。约束越可验证代理的表现越好你的验收也越轻松。这个道理其实不限于代理协作。带人的时候也一样模糊的要求得到模糊的结果具体的要求得到具体的结果。代理只是把这个规律放大了。最后再分享一个小技巧如果你不确定一个任务该不该交给代理先问自己一句——“这个任务里有多少是需要判断的有多少是纯执行的”如果判断占大头自己来如果执行占大头交给代理。这个简单的二分法帮我省了很多纠结的时间。 
长河君 · 2026/10/21 17:09:17 · 阅读 1.2k AI代理时代：为什么代码之外的判断力才是开发者分水岭
1. 从“能跑通”到“跑得漂亮”为什么代码之外的判断力才是分水岭写代码这件事门槛正在肉眼可见地塌陷。几年前我们还在争论“低代码到底能不能替代程序员”现在这个问题已经没什么人讨论了因为真正的问题变成了另一个当生成一段可运行代码的成本趋近于零时一个开发者、一个产品团队、一个内容创作者凭什么还能拉开差距我最近反复在琢磨一个词——品味。不是审美意义上的那种“好看”而是一种更底层的判断力面对十个都能跑通的方案你知道哪个是对的面对一堆功能都实现了的界面你知道哪个让人用起来舒服面对一段逻辑正确的代码你知道它三个月后会不会变成维护噩梦。这种判断力我把它叫做“超越代码”的部分。这个项目标题里提到的“超级智能AI代理”说白了就是那些能自主规划、调用工具、多步推理、甚至自我纠错的AI系统。它们确实越来越强强到可以帮你写完整模块、生成测试用例、重构遗留代码。但越是这种时候我越发现一个反直觉的现象工具越强使用工具的人的品味就越重要。因为工具能帮你把“做出来”这件事变得极其廉价但“做对”这件事依然需要人来拍板。这篇文章我想聊的就是这个。适合谁来读如果你是一个正在深度使用AI代理写代码的开发者或者是一个带团队做产品的技术负责人又或者是一个靠AI辅助做内容创作的人那这些经验对你应该有用。我会从方案选型、代理协作、实操流程、踩坑排查几个角度把“品味”这个听起来很虚的东西拆成能落地、能复现的具体动作。2. 核心思路拆解AI代理时代什么该交给机器什么必须自己扛2.1 先搞清楚“超级智能AI代理”到底强在哪、弱在哪很多人对AI代理的想象还停留在“我说一句它写一段”的阶段。实际上现在的代理系统已经能做到接收一个高层目标自己拆解成子任务调用搜索、读写文件、执行命令、调用API根据中间结果调整策略最后交付一个相对完整的结果。这个能力链条里规划、执行、纠错三个环节是核心。但它的弱点同样明显。我实测下来代理在以下几种场景里特别容易翻车目标模糊时你给的需求越笼统它越容易朝着一个“看起来合理但实际跑偏”的方向狂奔而且跑得越远纠偏成本越高。多方案权衡时它倾向于选“最常见”的方案而不是“最适合当前上下文”的方案。比如你让它选一个状态管理库它可能默认给你上最流行的那个完全不考虑你项目只有三个页面。边界条件处理时正常路径它能写得漂漂亮亮但异常分支、并发冲突、数据一致性这些地方它经常给出“理论上可行但工程上危险”的代码。所以我的核心思路是把代理当成一个执行力极强但判断力需要校准的初级工程师。规划的大方向、方案的取舍、边界的定义这些必须由人来把控具体的实现、重复的搬运、格式的转换大胆交给它。2.2 为什么“品味”不能被提示词完全替代有人会说那我把品味写成提示词不就行了比如“请选择最简洁的方案”“请考虑可维护性”。我试过效果有限。原因在于品味本质上是一种上下文敏感的权衡能力它依赖于你对当前项目阶段、团队能力、业务压力的综合判断而这些信息很难被完整地塞进一段提示词里。举个例子。同样一个功能创业公司三个月要上线和一家成熟公司做一个内部工具最优解可能完全不同。前者要的是“最快能跑、后面再重构”后者要的是“一次写对、少留技术债”。代理不知道你处在哪个阶段它只能按通用最优来。这个“按什么标准来最优”的判断就是品味。再往深一层说品味还体现在对“不做什么”的克制上。代理倾向于把所有能加的功能都加上把所有能写的抽象都写出来。但真正有经验的开发者知道很多抽象是过早的很多功能是不该做的。这种“减法”的判断目前只能靠人。2.3 一个可复用的协作框架人定标准代理执行人做验收基于上面的分析我摸索出一套还算顺手的协作框架分三步人定标准在让代理动手之前我先用几句话把“什么算好”定义清楚。比如“这个模块的对外接口不超过五个方法”“所有错误必须被显式处理不允许吞异常”“新增依赖必须说明理由”。这些标准不需要多但必须具体。代理执行把标准连同任务一起交给代理让它在一个有约束的空间里发挥。约束越清晰它的输出越稳定。人做验收代理交付后我不看它写了多少行而是对照最初的标准逐条检查。不符合的要么让它改要么自己动手改。这个验收环节是品味真正发挥作用的地方。这套框架的好处是它把人的精力从“写”转移到了“判断”上而判断恰恰是人比机器强的地方。下面我会把这套框架拆成更细的实操步骤。3. 核心细节解析把“品味”拆成可执行的检查项3.1 方案选型时的三个灵魂拷问每次代理给出一个方案或者我自己面对多个选择时我会问三个问题。这三个问题帮我过滤掉了大量“看起来不错但实际会后悔”的决定。第一个问题这个方案在最坏情况下会怎样代理通常展示的是正常路径但工程里大部分痛苦来自异常路径。比如它建议用一个内存缓存来加速查询正常情况确实快但如果缓存和数据库不一致了怎么办如果进程重启缓存全丢了怎么办把这些最坏情况想一遍很多花哨的方案就自动出局了。第二个问题三个月后一个不熟悉这个代码的人能看懂吗代理写的代码有时候很“聪明”用了各种语言特性和设计模式但聪明不等于好维护。我倾向于选择那些“笨但清晰”的方案哪怕多写几行。因为维护成本的大头不是写的时候而是读的时候。第三个问题这个决定可逆吗有些决定一旦做了后面改起来伤筋动骨比如数据库选型、核心架构分层。这种决定我会花大量时间反复权衡。而有些决定改起来很容易比如某个工具函数怎么写、某个配置放哪里。对于可逆的决定快速拍板让代理去执行对于不可逆的决定慢下来自己扛。3.2 代理协作中的“约束设计”技巧给代理下任务最忌讳的是“你看着办”。我的经验是约束要像给初级工程师写任务卡一样具体到可验证。比如我要让代理帮我重构一个模块我不会说“把这个模块重构一下”。我会说重构后对外暴露的函数不超过三个所有数据库操作必须通过已有的仓储层不允许直接调用每个函数不超过四十行不允许新增第三方依赖重构后原有测试必须全部通过这些约束里前四条是“品味”的体现最后一条是“正确性”的底线。代理在这五条约束下工作输出质量会稳定很多。而且这些约束本身也是我验收时的检查清单一举两得。还有一个技巧是分阶段交付。不要让代理一次性完成一个大任务而是让它先出一个方案大纲我确认后再让它写具体实现实现完再让它自己写测试。每个阶段我都有机会介入和纠偏。这比一次性拿到一大坨代码再回头改要高效得多。3.3 验收环节的“三看”原则代理交付后我的验收分三步一看结构文件组织是否合理模块边界是否清晰有没有出现“一个文件干所有事”的情况。结构不对后面全白搭。二看异常把所有错误处理路径过一遍。代理最容易在这里偷懒比如用空的catch块、用默认值掩盖错误、或者干脆不处理。我会特别关注那些“理论上不会发生”的分支因为线上事故往往就出在那里。三看命名变量名、函数名、类名是否准确表达了意图。命名是代码可读性的第一道关也是代理经常敷衍的地方。如果我发现一个函数叫handleData我会让它改成能说清楚“处理什么数据、怎么处理”的名字。这三看下来基本能过滤掉大部分质量问题。剩下的细节比如性能优化、边界微调可以后面慢慢来。4. 实操过程一个完整的代理协作案例拆解4.1 场景设定与目标定义假设我要做一个内部用的数据看板需求是从几个数据源拉取指标做简单聚合然后在一个网页上展示。团队只有我一个人时间预算两天。这个场景很典型需求不复杂但涉及多个环节数据获取、处理、展示而且我对“好”的定义很明确——能快速上线、后面好改、不引入不必要的复杂度。基于这个定义我先定了几条标准不引入前端框架用原生HTML加少量JS数据处理逻辑独立成一个模块方便后面替换数据源所有配置项集中在一个文件里不引入数据库数据直接内存处理这些标准定完其实方案已经收敛了大半。代理要做的是在这个框架里填充具体实现。4.2 分阶段下发给代理的任务清单我把整个任务拆成四轮对话第一轮方案确认。我把需求和标准发给代理让它先出一个技术方案包括文件结构、每个文件的职责、关键函数的签名。它给了一个方案我调整了两处一是它想用一个轻量模板引擎我砍掉了直接用字符串拼接二是它想把数据获取和处理混在一个文件里我要求拆开。第二轮核心逻辑实现。我让代理实现数据处理模块约束是输入是原始数据数组输出是聚合后的对象所有异常必须抛出不允许返回默认值函数不超过三十行。它写完后我检查了异常处理和命名改了两个变量名。第三轮展示层实现。让代理写HTML和JS约束是不依赖任何外部库数据通过一个全局函数获取页面加载后自动刷新一次。这部分它做得不错我只调整了样式细节。第四轮测试与文档。让代理为数据处理模块写单元测试覆盖正常路径和三种异常情况。然后写一个简短的README说明怎么配置数据源、怎么启动。四轮下来总共花了大概三个小时其中我花在“定标准”和“验收”上的时间占了一大半真正让代理写代码的时间反而不多。但最终交付的质量比我以前自己从头写要稳定得多。4.3 关键参数与配置的取舍记录这个案例里有几个取舍值得记录为什么不用前端框架因为页面只有一个交互只有刷新。引入框架带来的构建配置、依赖管理、学习成本远超它带来的便利。代理一开始建议用某个流行框架我否掉了。这个判断就是品味——知道什么时候不用重型工具。为什么数据处理要独立成模块因为数据源后面大概率会变。今天从A拉明天可能从B拉。把处理逻辑独立出来换数据源时只需要改获取部分处理逻辑不动。这个判断也是品味——为未来的变化留出接缝但不为想象中的变化过度设计。为什么配置集中在一个文件因为部署的时候只需要改一个地方。分散的配置是运维噩梦这个教训我踩过太多次。这些取舍代理不会主动帮你做因为它不知道你的部署环境、团队习惯、未来规划。这些信息在你脑子里你得自己判断然后把判断结果作为约束传给代理。5. 常见问题与排查技巧实录5.1 代理“跑偏”了怎么办代理跑偏的典型表现是你让它改A它顺手把B也改了你让它实现一个函数它给你重构了整个文件。遇到这种情况我的处理方式是立即停止不要让它继续往下写。跑偏的代码越多回滚成本越高。回退到上一个正确状态然后重新下发任务这次把约束写得更死。比如加上“只修改这个文件”“不要动其他任何文件”“不要重命名现有函数”。如果反复跑偏说明任务粒度还是太大继续拆。拆到它一次只能做一件小事为止。我踩过的一个坑是有一次让代理优化一个查询它把整个数据访问层重写了。虽然新代码确实更快但引入了两个新依赖而且原来的测试挂了一半。回滚花的时间比重新写还多。从那以后我给代理的任务卡上永远有一条改动范围不超过我指定的文件。5.2 代理写的代码“能跑但难看”怎么处理这种情况太常见了。代码逻辑没问题测试也过但读起来别扭命名随意、嵌套过深、重复代码多。我的处理分两种情况如果这段代码是临时的、一次性的我忍了不花时间改。品味要用在刀刃上不是所有代码都值得打磨。如果这段代码是要长期维护的我会让代理自己改。具体做法是把我觉得难看的地方指出来告诉它“这里命名不清晰”“这里嵌套太深”让它重写。通常它能改好因为“难看”这件事指出来之后它是有能力修正的。但如果改了两轮还不行我就自己动手。跟代理较劲的时间成本有时候比自己写还高。5.3 如何判断一个代理是否“值得用”不是所有代理都值得投入时间。我判断的标准很简单看它在约束下的表现。给它一个明确的任务和几条清晰的约束看它能不能在不违反约束的前提下完成任务。如果能说明它值得培养如果它总是“自作主张”突破约束或者需要你反复提醒同样的要求那它可能不适合你的工作流。还有一个观察点是纠错能力。你指出一个错误后它是只改这一处还是能举一反三检查同类问题后者说明它有“理解”而不只是“匹配”。这个能力在长期协作中非常关键。5.4 常见问题速查表问题现象可能原因处理方式代理改动范围超出预期任务约束不够具体明确指定可修改的文件和函数代码能跑但异常处理缺失代理倾向走正常路径验收时专门检查所有catch和错误分支命名随意、可读性差代理缺乏项目上下文提供命名规范或让它参考现有代码风格反复犯同一个错误约束没有形成检查清单把要求写成可验证的条目每次验收对照方案过于复杂代理倾向“通用最优”明确项目阶段和约束条件砍掉不必要抽象测试覆盖不足代理默认只测正常路径要求覆盖至少三种异常情况6. 影响范围分析这套方法适合谁、不适合谁6.1 最适合的场景个人开发者与小团队快速交付这套“人定标准、代理执行、人做验收”的方法在个人开发者和小团队里效果最明显。因为这种场景下决策链条短标准容易统一代理的输出能直接被验收和使用。我自己用这套方法做过几个内部工具从想法到可用版本基本都在一天以内而且后面改起来不痛苦。另一个适合的场景是原型验证。当你需要快速验证一个想法时让代理把架子搭起来你专注于核心逻辑和关键判断能省下大量时间。原型阶段对代码质量的要求可以放宽品味主要体现在“快速验证核心假设”上而不是“写出漂亮代码”。6.2 需要谨慎的场景大型遗留系统与强合规环境如果你的项目是一个跑了多年的大型系统或者处在强合规、强审计的环境里那这套方法要谨慎使用。原因在于代理对遗留系统的上下文理解几乎为零它给出的方案很可能与现有架构冲突或者违反某些隐性的约定。这种场景下代理更适合做局部辅助比如写测试、生成文档、做代码审查的初筛而不是直接改核心逻辑。强合规环境还有一层问题代理生成的代码责任归属不清晰。如果出了问题是写提示词的人负责还是验收的人负责这个在流程上需要提前想清楚。6.3 对开发者能力结构的影响往大了说这套协作方式正在改变开发者的能力结构。以前我们强调“写得快、写得多”现在“写得快”这件事正在被代理接管真正稀缺的是判断力判断什么该做、什么不该做、什么现在做、什么以后做。这意味着如果你还在靠“熟练度”吃饭压力会越来越大。但如果你有意识地在日常工作中训练自己的品味——每次做决定时多问一句“为什么选这个不选那个”——那你的价值反而会放大。因为代理再强它也需要一个人来告诉它“什么算好”。我个人的体会是自从开始用代理协作我花在“想”上的时间明显变多了花在“敲”上的时间变少了。这个转变一开始不太适应但慢慢发现想清楚之后再动手返工率低了很多。这可能就是标题里说的“超越代码”的意思——代码本身越来越不值钱代码背后的判断越来越值钱。7. 我踩过的坑与几条实在建议7.1 不要用代理来逃避思考这是我最想分享的一条。代理最危险的地方是它让你产生一种“我在干活”的错觉。你不停地发指令、收结果、再发指令看起来很忙但实际上你只是在做搬运没有在做判断。时间长了你的判断力会退化。我的做法是每天留出一段时间关掉代理自己写一点代码或者至少自己读一点代码。保持手感也保持判断的敏锐度。代理是工具不是拐杖。7.2 标准要写下来不要留在脑子里我一开始觉得标准这种东西自己心里清楚就行了不用写出来。后来发现写下来有两个好处一是给代理看它的输出会更稳定二是给自己看验收的时候有据可依不会因为“感觉差不多”就放过去。我现在习惯在项目根目录放一个STANDARDS.md里面列着这个项目的几条核心原则。每次让代理干活之前我会把相关条目贴给它。这个习惯帮我省了很多来回沟通的时间。7.3 验收时不要只看“能不能跑”“能跑”是最低标准不是验收标准。我见过太多代码测试全绿但结构混乱、命名随意、异常处理缺失后面改一个小需求就要动五个文件。这种代码的维护成本会在几个月后集中爆发。所以验收的时候我强制自己看三样东西结构、异常、命名。这三样过关了才进入下一轮。这个习惯一开始很累但坚持一段时间后代理的输出质量会明显提升因为它知道你会检查这些。7.4 给代理的约束要“可验证”“代码要清晰”这种约束代理没法执行因为它不知道什么叫清晰。但“函数不超过四十行”“不允许空的catch块”“新增依赖必须说明理由”这些是可验证的。约束越可验证代理的表现越好你的验收也越轻松。这个道理其实不限于代理协作。带人的时候也一样模糊的要求得到模糊的结果具体的要求得到具体的结果。代理只是把这个规律放大了。最后再分享一个小技巧如果你不确定一个任务该不该交给代理先问自己一句——“这个任务里有多少是需要判断的有多少是纯执行的”如果判断占大头自己来如果执行占大头交给代理。这个简单的二分法帮我省了很多纠结的时间。