AI做原型易，改原型难——Harness在原型调整skill中的应用

当AI遇上原型修改，看似简单的调整为何频频翻车？从弹窗样式错乱到同名函数覆盖，AI自信满满的‘已完成’背后隐藏着底层行为模式的致命缺陷。本文通过5轮实战案例，揭秘如何用Harness思想构建四步强制流程+全局硬约束，将AI从‘人工智障’驯化成可靠的‘能工智人’，实现从盲盒式修改到可预期协作的蜕变。

一、做原型易，改原型难

用AI画产品原型，已经是一件门槛极低的事了。

你给AI描述一下页面结构，它几十秒就能输出像模像样的HTML页面。乍一看AI画原型的速度已经远超古法手搓原型的速度。

但当你想让AI改一个已经做好的原型时，往往一个很简单的调整要经过好几轮修改才能改好。而且AI每次都会自信满满说改完了、哦我知道了、明白了、我看到了、这次一定对。

创建是从无到有，AI随便发挥，约束少、自由度大，出错概率低。修改是从有到好，AI需要在现有结构上精准操作——不能破坏已有的逻辑、不能影响周围的元素、不能丢掉用户已经确认过的功能。它面对的不是一张白纸，而是一张写满了字的纸，要擦掉一行、替换一个词，还不能弄皱其他部分。

二、典型案例

曾经我让AI改一个功能——弹窗里面有一组单选按钮，对应不同的生成频率：每日、每周、每月、每季度、每半年、每年。选中某个频率后，会显示对应的时间配置区域。我想让AI改bug：切换频率时，上一个频率的时间配置不会消失，导致页面上同时显示多个配置区域。

然后经过反复调整才改好：

第一轮，它怀疑是弹窗的CSS样式冲突，调整了CSS和弹窗结构，没改好。

第二轮，它重新检查了HTML结构，发现”每日”区域缺少一个初始隐藏属性，补上了，没改好。

第三轮，它发现了另一个问题：弹窗显示时会设置内联样式，但切换频率时只移除了隐藏标记，没清除内联样式。它让我在浏览器控制台里测试了修复代码，效果正常。然后写入文件，控制台测试能过，但实际不行。

第四轮，它开始怀疑是浏览器缓存问题，让我强制刷新、清缓存。我照做了，依然不行。

第五轮，它搜索了源码中切换函数onFreqChange的所有定义，结果发现页面里有两个同名函数。第2369行是一个修复后的版本，第2595行是一个旧版本。在JavaScript里，后定义的函数会覆盖先定义的。也就是说，不管第2369行写得多正确，每次页面加载时都会被第2595行的旧版本覆盖。前4轮所有的修复，从来没有真正被执行过。删掉旧版本，只保留新版本，问题解决。

这5轮调整，AI每次改完都说”已完成”“已修复”，语气非常笃定，但每一轮都没有解决问题。让AI自己复盘，它把失败原因分成了三层：

执行上，只关注”改得对不对”，没关注”改上去是否生效”。

流程上，缺”修改后验证”环节，遇到问题就瞎猜（比如怀疑缓存）。

设计上，排查清单里根本没有”源代码中是否还有同名定义”这一项。

所以问题不是出在这一次修复上，而是出在AI的底层行为模式上，我必须约束AI的行为。

三、建立多个skill进行流程约束

借助Harness思想，当时我想，既然AI太随性，那就建立多个技能，一步步严谨地执行。

于是我建立了5个独立的技能：

需求分析——理解我提出的问题和需求，不要自己猜测

代码审查——改之前先通读页面，找出所有潜在问题

修复建议——针对每个问题给出具体的修复方案

建议检查——自己评估修复方案是否可行，有没有遗漏

自检验证——修改完成后，自己检查是否按需求调整完毕

需求分析是我最早想到要加的。因为实际用下来我发现，AI经常理解错我的意思，我有时候会说”你不要着急，先理解我的意思再改”，所以我抽象出”需求分析”作为前置环节——先搞清楚我要什么，再动手改。

代码审查是让AI在动手之前先通读现有页面，看看有没有隐藏的问题——比如同名函数、重复ID、嵌套不对齐。这些如果提前发现，后续修改可能效率更高。

修复建议和建议检查一个出方案一个审方案。出方案容易漏掉边界情况，需要增加道审核：完整吗？有逻辑矛盾吗？超出了我的要求吗？等等

自检验证是最后一道关卡，改完不能直接说”已完成”，要先验证效果，确实生效了、并且没有影响其他功能再输出给我。

实际确实有用，但也有一些问题：受制于AI工具本身，并不能理想地主动调用技能，比如我明明规定代码审查之后必需要进行修复建议，但有时候AI会忘。我问AI为什么，它说它认为不需要。既然AI会漏，干脆我手动调用全部技能，因为在我的逻辑中，这些技能是一串的，都应该被调用。所以最终大多数时候都是由我手动调用全部技能。

五个技能是松散的描述，AI无法实现必须执行某环节、必须按顺序执行，它有自己的判断，所以会跳过它认为”不需要”的环节。想象中的AI自动”视情况调用”，在实践中变成了手动的”我全要”。

四、加入新的skill统领全部技能

既然AI做不到多技能工作流，那干脆新建统筹性的skill，而且我希望如果简单的调整，AI直接改，但复杂的需要按照我规定的流程调整。于是我又创建一个原型调整skill，统筹其他技能，并加入判断——“若调整简单，只调用代码审查和自检验证两个技能；若调整复杂，需要调用所有技能，并严格按照需求分析→代码审查→修复建议→建议检查→自检验证的流程，且任一环节不通过就返回上一环节”。

合并之后确实好了很多，但也有问题：

1.就算判定为复杂调整，AI也会偶尔遗漏一些环节

2.不仅我没有判断简单或复杂调整的能力，AI也没有

比如去掉一个弹窗按钮，我和AI都以为很简单，仅调用了代码审查和自检验证，然后又经历了弹窗打不开、右上角关闭按钮消失、关闭按钮跑到弹窗外面、标题跑进内容区、弹窗又打不开、调整成功6轮修改。弹窗如下（当时要去掉的是右上角的关闭按钮）：

所以必须去掉难易的判断，凡改原型必须走完整流程。

五、最终方案：4步强制流程+全局硬约束

在实际使用过程中，我发现需求分析其实可以在提需求时自己想清楚，不需要单独作为一个技能让AI执行。去掉需求分析后，流程变得更简洁。而且之前创建需求引导skill的心理活动纯粹是为了流程而流程，不能为了用AI而AI。

最终将所有技能合并为原型调整这一个技能，所有修改统一走完整的流程：

Step1:审查——改之前先看全貌

拿到需求先别动手，通读现有页面的代码，列出所有可能受影响的地方。这一步防的是改了A坏了B。

Step2:方案——列出修改计划

先写出完整的修改计划，标注每项修改会影响哪些地方，别想到哪改到哪。

Step3:评估——自己检查方案

方案写完，自己用一张检查清单过一遍：逻辑对不对？语法对不对？影响范围有没有遗漏？有没有超出用户要求？

Step4:执行+验证——改完必须看到结果

执行修改后，确认没问题才交付，防止AI一味地说改好了。

为保证及时调用技能，我让AI在全局记忆里写了两条硬性规则。

凡是要改HTML页面，必须先加载原型调整技能。不加载就直接改，属于违规。

改完必须验证，验证通过才能交付。不验证就说“已完成”，属于违规。

从”靠自觉”变成了”靠系统”，终于给AI加上了马鞍。

六、回顾与总结

用了这套流程之后，之前反复出现的几类典型错误——弹窗层级搞乱、样式混用、标签没闭合、引用不存在的功能、改了A坏了B——虽然偶尔还会出现，但频率低了很多。

回顾本次用AI调整原型的经历，总结了有几条经验分享给大家：

技能不是万能的。4步自检只是我在PC端某特定系统积累的经验，虽然规则尽可能保证通用，但肯定有所不足，所以遇到新的错误类型一定要及时归纳补充到技能里，并及时让AI辅助分析该技能的规则只适用于特定项目还是能通用。

比如通过对典型案例的总结，AI帮我更新了以下规则：

代码审查技能：更新了同名定义的检查规则

修复建议技能：更新了同名函数的检查规则

执行修复技能：更新了同名定义、用户验证、控制台vs源码的检查规则（PS.当然，除此以外还更新了全局记忆和项目记忆，比如诚实准则、能力边界、项目经验、排查清单等。）

AI的输出一定要验证。别信AI的”已完成”，改了好几次都没好它也说没问题，必需用全局规则或技能约束，用系统规则替代AI的自我判断。

流程该走的别省。自以为”去掉一个按钮”很简单，不走完整流程，结果变成了多轮返工。后来我把简单/复杂分流去掉了，凡改必走完整流程，虽然每次多花了一点时间，但AI慎行比返工效率高。

人工智障+能工智人的配合。AI不是许愿机，好多情况只能输出个大概样子，在改原型或者用AI做其他事的过程中发现AI经常出问题，要借助AI归纳总结，制定约束方案，用实际流程去约束它。从画原型、改原型到创建并维护skills的经历，本质上是HarnessEngineering的一次简洁实践，虽然不完美，但让AI改原型从”开盲盒”变成了”可预期”。

这件事的本质，其实不是在”教AI做事”，而是在设计一个人机协作的执行标准。AI负责执行，人负责定义流程和验收标准——给AI套上马鞍，它跑起来才可控。这套方法适合任何需要AI执行多步骤任务的场景：改代码、写文档、做数据分析——只要是需要AI”做完一件事”的任务，都可以用类似的思路设计流程。

附：原型调整skill

https://github.com/yangcr-abaaba/prototype-adjustment