AI研发流程初步实践（五）：边界问题与人工介入

发表于 更新于 分类于 ，
AI擅长与不擅长的领域划分、必须人工介入的四个场景、五个典型踩坑案例（跳测试、plan写代码、重复失败、误读意图、过度工程化）、约束即自由的协作哲学

如果你刚接触AI辅助开发，很可能会有两种极端感受：有时候AI像神一样——给你写出完美的代码、连测试带文档一步到位、速度比你快十倍；有时候AI又像猪队友——写出你从未要求的功能、引入你明确说不要的依赖、在同一个错误上反复跌倒十次。

这两种感受都是真实的。AI不是”万能”也不是”废物”，它是一台在某些领域极强、在某些领域极弱的工具。理解它的能力边界，是有效协作的前提。这篇文章帮你建立一张”AI能力地图”——什么它擅长、什么它不擅长、什么时候你必须介入、哪些坑是高频踩的。

一、概念：AI的能力地图

有效利用AI的第一步，是承认它有清晰的能力边界。下图直观展示了AI在开发中的能力地图——绿色区域是AI擅长的，红色区域是AI不擅长的，中间的分界线就是人工介入的关键时机：

AI能力边界图

这不是贬低AI，而是理性认识工具。就像你不会用电钻切菜、用菜刀钻孔，你也不该让AI做它不擅长的事。

1.1 AI擅长的领域

AI在以下场景表现稳定可靠，可以给予较高信任度：

  • 模式化代码编写。CRUD接口、DTO转换、配置文件的boilerplate、相似结构的重复代码。这类代码模式固定、规则清晰、变化有限，AI写得又快又准。给它一个已有的类似文件做模板，它能批量生成一整套。

  • 测试用例生成。给一个函数，AI能快速列出正常输入、边界输入、异常输入的测试矩阵。它尤其擅长穷举边界条件——空数组、单元素、最大值、负数、null值——这些人类经常遗漏的场景，AI反而记得很清楚。

  • 技术文档撰写。把代码逻辑翻译成人类语言，AI很在行。README的功能描述、CHANGELOG的版本记录、JSDoc的接口说明、架构文档的模块解释，AI写得比大多数开发者自己写的更详细、更结构化。

  • 代码重构（行为不变）。重命名变量、提取公共函数、引入抽象层、调整文件结构——这类”行为不变、结构变”的活，AI在测试保护下能高效完成。注意前提是”有测试保护”。没有测试的重构，AI和人类一样可能引入错误。

  • TDD红绿循环执行。先写测试，看到RED，写实现代码，看到GREEN——这套循环AI执行得很机械。”机械”在这里是褒义词，意味着可靠、可重复、不受情绪影响。

这些领域的共同特征是什么？规则明确、反馈即时、结果可验证。AI写这段代码对还是错，可以通过测试、类型检查、lint规则立刻判断。错误会立即暴露，修正成本低。

1.2 AI不擅长的领域

AI在以下场景经常出错或给出糟糕结果，需要主动限制它的参与：

  • 跨版本架构决策。决定”这个抽象该不该引入””这层该不该拆””这个接口该不该统一”。AI没有项目的长期记忆，它看到的是当前代码状态，看不到代码的演进历史。它倾向于”加抽象”——因为训练数据里”专业代码”经常是抽象的——但很多抽象对当前项目是过度设计。

  • 需求歧义消解。需求描述里有”看情况””灵活””未来可能需要”这类模糊表述时，AI不会反问”你具体指什么”，而是会自己脑补一个完整解释。而它脑补的解释，大概率不是你真正想要的。

  • 视觉审美与UI设计。页面的间距、配色方案、字体大小、动效节奏——AI没有”看起来舒服”的判断力。它能生成符合CSS规则的代码，但生成不出有品味的视觉设计。

  • 性能微调优化。把一段代码从100ms优化到50ms，需要理解运行时特性、profiling数据、瓶颈定位。AI倾向于”看起来更优雅”的改写——减少嵌套、用函数式替换命令式——但”更优雅”不等于”更快”，有时候反而更慢。

  • 商业判断。功能优先级排序、目标用户定义、商业风险权衡。AI不知道你的业务上下文，它给的优先级建议经常偏离实际需求——因为它的训练数据里”最佳实践”是通用场景的，而你的业务是独特的。

这些领域的共同特征是什么？判断标准模糊、需要长期上下文、依赖审美或经验。AI在这些领域犯错时，错误不会立刻暴露。它写了一段”看起来对”的代码，但架构决策错了——等三个月后需要扩展那个模块时才发现当初选错了抽象，但此时改造成本已经很高了。

二、通用设计方案：边界意识与人工介入

理解了AI的能力边界，下一步是把理解转化为协作中的具体规则。这套方法论由”四个必须介入场景”和”五个典型踩坑案例”组成，核心是一句话：在AI擅长的地方信任它，在AI不擅长的地方约束它。

2.1必须人工介入的四个场景

以下四类场景不能交给AI自主决策，必须人工介入。介入的方式不是”不让AI参与”，而是”AI提案、人决策、AI执行”。

场景一：架构方向

引入新分层、删除现有抽象、切换技术栈、调整模块边界——这些决策影响深远。AI看不到三步之后的连锁反应。你做了一个”加一个抽象层”的决策，可能在下个版本导致所有新代码都要过两层。这个决策该不该做、怎么做、什么时候做，必须由人来定。

协作方式：让AI列出选项和各自利弊，你选方向，AI执行具体改动。

场景二：用户偏好

UI风格、交互节奏、文案语气、命名习惯——这些是主观的。AI的”最佳实践”不一定符合你的偏好。比如AI倾向于把按钮放在页面右侧浮动，但你更喜欢底部固定。AI倾向于用”查询”作为搜索框占位符，但你想用”搜点什么”。

协作方式：把偏好明确写在project_memory里，让AI有据可依。偏好变化时主动更新。

场景三：安全边界

权限模型、密钥管理、输入校验、信任边界——这些出错的代价极高。AI的默认倾向是”先让它能跑”，安全经常在权衡中被牺牲。它会写出不校验输入、不处理越权、不加密传输的代码，因为”当前版本先确保功能”。

协作方式：安全规则必须工具化。不能只提示”注意安全”，而是用约束——输入校验模板、SQL注入防护规则、密钥读取必须走固定API——让AI没有跳过安全的路径。

场景四：商业判断

功能优先级、目标用户、技术选型的业务权衡。AI不知道你的项目为什么存在、用户是谁、什么功能才是核心价值。它给的优先级建议经常是一份”功能大全”——把所有可能的功能都排上，因为”全”看起来最专业。但你知道哪些功能是核心、哪些是锦上添花。

协作方式：spec阶段你定优先级，AI只负责实现优先级内的事项。

2.2踩坑案例一：AI跳过测试直接写实现

现象： 你让AI实现一个功能，它直接写出了完整的实现代码，没有先写测试。你问”测试呢”，它回答”测试我等下补”，或者”这个功能很简单，不需要测试”。

后果： 写出的代码”看起来对”，但运行时才发现引用了不存在的API、漏掉了边界条件。等”等下补”的测试永远不会来——因为下一个功能已经在等它了。

为什么AI会这么做： 因为跳过测试直接写实现是”更短的路”。AI是目标导向的——你的目标是”实现这个功能”，它选择最短路径完成。写测试是额外步骤，如果没有被强制要求，AI会选择跳过。

对策： 用流程强制TDD，不是用提示词建议。提示词级别的”请用TDD”会被AI当成”建议”——它口头上答应，但写代码时选择性忽略。必须用工具级的约束：在写实现代码之前，强制AI先写测试、运行测试看到RED、然后才能写实现。工具框架可以做到”不写测试不让写实现”的强制顺序。

教训： 约束要工具化，不能停留在提示词。提示词是建议（AI可以选择性遵守），工具是流程（AI必须走完）。

2.3踩坑案例二：AI在plan里写实现代码

现象： 你让AI写一个实施计划（plan），它给出的不是”任务清单 + 验证步骤”，而是”完整实现代码 + 简短说明”。plan变成了代码草稿。

后果： plan阶段的代码无法被验证——因为没有测试驱动它。AI把plan当做”待粘贴的草稿”，实现阶段直接复制这些代码，TDD红→绿循环失效。代码的错误在plan阶段就埋下了，到测试阶段才暴露，回溯成本高了很多。

为什么AI会这么做： AI的训练数据里，”plan” 和 “代码” 经常混在一起——很多技术博客的 “实施计划” 就是贴代码。AI学到了这种模式，不知道你的项目里plan和实现是分离的。

对策： 在约束文档里明确写清楚”plan只写描述性内容，不写实现代码”。plan是给AI自己看的任务清单，不是代码产出。实现代码只能在TDD循环里写。AI如果在plan里写了代码，主控agent（你或者上层编排器）应该拦截并要求重写。

教训： 文档分层要显式声明。AI不会自己分辨plan / spec / design的边界，必须在约束里明确告诉它每个文档允许什么内容。

2.4踩坑案例三：AI在同一个错误上反复失败

现象： 某个测试连续失败。AI换一种方式重试——改变量名、调参数、调整import顺序——但根本思路没变。重试五次十次都没过，token烧了一堆，时间浪费了，最终结果还是错的。

更糟糕的变体： AI可能”偶然”把测试改绿——不是通过修复代码，而是通过弱化断言、跳过某些case、mock掉了真实逻辑。这种”假绿”比”真红”危险十倍。真红还能让你知道有问题，假绿会让你以为功能是好的，直到生产环境出bug才发现测试测了个寂寞。

为什么AI会这么做： AI没有”停下来想想”的元认知能力。它不会主动说”这个方案可能不对，我应该换个思路”。它的默认行为是”在当前方向继续微调”——换了人类开发者，试三次不过就会质疑方案本身；AI试十次不过还是会继续微调。

对策： 引入熔断机制。同一个subtask连续3次失败，强制停止、记录失败信息、跳过这个subtask、进入回顾环节。回顾不是问”怎么再试一次”，而是问”是不是subtask拆错了？是不是spec的决策有问题？是不是这个功能当前不应该做？”。3次失败通常意味着方向错了，不是细节没调对。

教训： AI辅助开发必须有止损机制。AI没有”停下来想想”的能力，必须用流程强制它停。

2.5踩坑案例四：AI误读用户意图

现象： 你说”加个搜索框”，AI理解成”实现全文搜索 + 模糊匹配 + 搜索高亮 + 搜索历史 + 热门搜索推荐”。实际你只是想要一个”简单的精确匹配输入框”。AI把你的”加个搜索框”脑补成了”完整的搜索功能”。

后果： AI实现了一大堆你没要求的功能，违反了YAGNI原则。代码膨胀、测试膨胀、维护成本膨胀。你得到的是一个”看起来很专业”但”不是你要的东西”的产品。

为什么AI会这么做： AI的训练数据里，”做一个功能” 经常关联着 “做得完整”。一个人说”加个搜索框”，技术文章里会展开成”如何设计一个完整的搜索系统”。AI学到了这种关联，所以它倾向于”最完整的版本”。而且”完整”意味着”显得专业”——AI被训练成尽量让输出看起来专业。

对策： 在spec阶段明确标注”不做什么”。比如”搜索功能：精确匹配，不支持模糊搜索，不支持搜索历史，不支持拼音纠错”。把”不做什么”写清楚，比只写”做什么”更能约束AI的输出范围。另外，要求AI在遇到模糊需求时主动用AskUserQuestion澄清——“搜索框要精确匹配还是模糊匹配？需要搜索历史吗？”——优先反问，而不是默认做最全版本。

教训： 歧义要问，不要猜。AI的脑补经常是”最全的版本”，但你要的通常是”最小的版本”。主动澄清比事后回退成本低得多。

2.6踩坑案例五：AI过度工程化

现象： 你让AI实现一个简单的功能——比如从JSON文件里读配置——它引入了抽象工厂、策略模式、配置驱动、插件机制。代码”看起来很专业”，有完整的设计模式、多层抽象、接口定义。但这个功能本身只需要20行。

后果： 维护成本远超功能价值。改一个简单的行为——比如加一个配置字段——现在要动四个文件、理解三层抽象。下个版本想加功能，发现抽象层挡着路，AI建议”再加一层抽象”来解决——抽象嵌套继续膨胀。

为什么AI会这么做： AI的训练数据里，”专业代码” 经常伴随着抽象。它学到了”抽象 = 专业”。但它不知道你的项目规模、不感知”一个20行的功能不需要设计模式”。它用”看起来专业”替代了”实际合适”。

对策： 在project_memory里明确写”YAGNI是硬约束——只实现当前需求，不预留未来扩展”。AI提出设计模式或抽象时，要求它论证”为什么这个抽象在当前版本是必要的”，而不是”未来可能需要”。另外，你可以限制”单文件最大行数””每个功能模块的接口数量”作为检视指标——指标越线就要重新评估是否过度设计。

教训： AI倾向于过度设计。你需要主动压制这个倾向。”简单 = 专业”在大多数项目里是比”抽象 = 专业”更正确的判断。

2.7约束即自由

五个踩坑案例，五个不同的表象，但指向同一个核心问题：AI在没有约束时不会做出最优选择。它会在”最短路路径”（跳过测试）、”最完整方向”（过度实现需求）、”最专业表象”（过度抽象）之间做默认选择——但这些选择不一定对你的项目有利。

这就是”约束即自由”的哲学：表面上约束限制了AI的自由，但实际上约束让AI在它擅长的领域自由发挥，同时阻止它在不擅长的领域制造混乱。

具体来说，约束起到了三个作用：

  • 聚焦：把AI的能力集中在它擅长的领域（模式化代码、测试、文档、重构、TDD执行），让它在那里全力发挥。
  • 止损：在AI不擅长的领域设置边界（架构决策归人、模糊需求主动问、3次失败强制停），防止它在一个错误方向上跑得太远。
  • 信号：约束不是为了限制而限制，而是提供信号——当约束被频繁触发时（比如同一个subtask反复熔断），说明问题不在AI的执行，而在更高层（spec设计、任务拆分、需求定义）。

约束即自由不是口号，是协作的基本契约。你给AI清晰的边界，AI给你稳定的输出。

三、市面其他方案对比

面对AI的能力边界问题，不同的项目和团队采取了截然不同的态度。大致有三种典型路线。

3.1方案A：全盘信任AI

这种方案的核心态度是”AI说的都对”。开发者把几乎所有任务交给AI，包括架构决策、安全设计、需求分析。AI输出什么就接受什么，不做review，不设熔断机制。

适用场景： 原型快速验证、一次性脚本、个人娱乐项目（不涉及生产环境和用户数据）。

优势： 开发速度最快，几乎没有人类干预的延迟。AI从零到完成一条龙。

代价： 质量完全不可控。AI可能在安全、架构、性能等方面埋下隐患，而这些隐患只在生产环境或项目后期才暴露。没有熔断机制意味着AI会在一件事上浪费大量token和时间。没有review意味着”看起来对但实际错”的代码会被直接合并。

方案A的合理性在于场景匹配——做一次性的原型，确实不需要严格的质量管控。但把方案A用到产品级项目上，就是赌博了。AI的错误率不是零，而在产品级项目中，错误率的代价可能是用户的信任或生产事故。

3.2方案B：全盘怀疑AI

这种方案走另一个极端：不信任AI的一切输出。AI写的每一行代码都要人工review，每一个决策都要人工确认。AI被当做一个”速度慢但偶尔有用的打草稿工具”。

适用场景： 安全敏感项目、合规要求严格的项目、开发者对AI能力边界认识不足的新手期。

优势： 安全性最高，人的判断覆盖每一个决策点。不会出现AI在安全或架构上埋雷的情况。

代价： 失去了AI辅助开发的核心优势——效率。如果AI的每一行输出都要人工逐行审核，那用AI的意义就大打折扣了。更糟的是，如果从”不信任”出发，人会倾向于重写AI的代码而不是优化它，导致”AI写 → 人重写”的效率负循环。

方案B的问题在于”不分场景，一律怀疑”。AI在模式化代码、测试生成、文档撰写上表现非常好，这些场景应该信任它。全盘怀疑意味着你在自己最累的地方也不让AI帮你。

3.3方案C：边界意识 + 工具化约束 + 熔断机制

这是前面”通用设计方案”描述的方法论。核心态度是”信任但验证”——理解AI的能力边界，在它擅长的领域给予较高信任度，在它不擅长的领域用约束限制它。

具体特征：

  • 边界意识：团队有清晰的”AI能做什么、不能做什么”的共识。不是写在墙上的口号，而是贯彻在每次协作中的原则。
  • 工具化约束：不是用提示词”建议”AI怎么做，而是用流程强制AI按规范执行。TDD不是”请用”，是”必须先写测试”。熔断不是”如果失败了请停止”，是”3次失败自动停止并记录”。
  • 人工介入有节奏：不是”所有决策都要人审”，而是”架构方向、安全边界、商业判断、用户偏好这四类必须人定”。其他事情放手让AI做。
  • 持续校准：每次版本冷却期，重新审视AI的能力边界。模型升级后，某些以前AI不擅长的可能变得擅长了，某些以前擅长的可能因为模型行为变化变得不可靠了。边界是动态的。

适用场景： 产品级项目、持续迭代项目、人机协作成熟期。

优势： 平衡了效率和质量。AI在擅长领域自由发挥，人在关键节点保持掌控。流程化约束保证了协作的稳定性和可预测性。

代价： 需要投入精力设置和维护约束体系；需要对AI的能力边界有持续认知（而不是”设完不管”）。

3.4设计哲学对比

维度 方案A（全盘信任） 方案B（全盘怀疑） 方案C（边界意识+约束）
核心态度 AI说的都对 AI说的都不可信 信任但验证
测试策略 AI自测或跳过 人工写测试 TDD强制 + AI生成
架构决策 AI决定 人决定 AI提案 + 人决策
熔断机制 无 无（但人全程审查） 3次失败自动熔断
安全性 风险高 最安全 规则约束 + 人审关键点
开发速度 最快 最慢 中等（但可持续）
适用阶段 原型验证 安全敏感 产品迭代

三条路线的本质差异在于”把AI当什么”：方案A把AI当全能的替代者，方案B把AI当不可信的辅助笔，方案C把AI当有特长的协作者。

四、aptbot的设计特点

aptbot选择方案C作为协作基础。不是因为它”最先进”，而是因为它最适合学习型项目的定位——aptbot既要高效开发，又要保持代码质量和可理解性，还要示范”如何正确地与AI协作”。

具体实践中，aptbot通过以下机制实现边界意识：

工具化TDD约束。 aptbot的TDD不是写在提示词里的”请用TDD”，而是通过test-driven-development skill强制执行的。AI在写任何实现代码之前，必须经过”写测试→运行看到RED→写实现→看到GREEN”的完整循环。AI无法”跳过测试先写代码”——如果试图跳过，skill会拦截并引导回TDD流程。

plan不含代码规则。 aptbot的工作流文档明确写死了”plan只包含任务描述和验证命令，不包含实现代码”。AI如果在plan阶段写了代码，主agent会检测到并要求重写。这个约束确保TDD循环不被plan阶段的”预写代码”破坏。

3次熔断机制。 每个subtask有明确的失败计数器。同一个subtask连续3次执行失败会自动停止，记录失败原因、当前状态、尝试过的方案，然后跳转到冷却/回顾流程。熔断不是”放弃那个功能”，而是”先回顾再决定怎么继续”——可能的结果包括：调整subtask拆分方式、修改spec设计、或者暂时搁置这个功能。

AskUserQuestion优先。 遇到模糊需求时，AI的默认行为不是”猜测最可能的意思然后执行”，而是”列出歧义点让用户选择”。这个行为不是通过提示词”建议”的，而是通过约束配置为默认行为。

YAGNI硬约束。 project_memory里写明了YAGNI是硬约束。AI在提议抽象或设计模式时，必须论证”为什么当前版本需要它”，不能以”未来可能需要”作为理由。这个约束直接压制过度工程化倾向。

人工介入的四象限。 aptbot明确了四个必须人工决策的场景（架构方向、用户偏好、安全边界、商业判断），并在工作流中标注了这些”决策点”。AI在这些点上只负责提供选项和利弊分析，不做最终决定。

aptbot的设计传递了一个核心理念：约束不是对AI的限制，是对AI的保护。有边界的AI才是可靠的协作者。

五、发展方向

AI的能力边界不是固定的。随着模型升级、工具演进、方法论成熟，边界在不断推移。几个趋势值得关注：

能力边界动态化。 今天的”AI不擅长”可能是明天的”AI擅长”。比如视觉审美——当前AI没有审美判断力，但视觉生成模型正在快速发展。性能微调——随着AI对运行时理解的加深，未来可能能给出更精准的优化建议。边界意识需要持续更新，不能设定了就不管。

自动化的边界检测。 未来可能出现自动化工具，在AI执行任务时实时检测它是否越过了能力边界——比如检测到AI在做架构决策时自动告警，或者检测到同一个错误重复3次时自动触发熔断而不需要人工配置。

基于风险的信任分级。 不同的改动类型有不同的风险等级。低风险（修typo、改常量、加注释）可以全自动；中风险（加测试、重构内部函数）可以AI执行+人抽查；高风险（架构调整、安全逻辑）必须人审批。信任不再是一刀切的”信任/不信任”，而是基于风险的梯度信任。

aptbot会持续跟踪这些趋势，在后续版本中迭代协作方法论。但核心原则不变：理解边界不是为了限制AI，而是为了让AI在它最强的地方更好地帮助你。

小结

这篇文章的核心信息可以浓缩为三句话：

  1. AI有清晰的能力边界——它擅长模式化代码、测试、文档、重构和TDD执行；不擅长架构决策、需求歧义、视觉审美、性能微调和商业判断。
  2. 必须人工介入四类场景——架构方向、用户偏好、安全边界、商业判断。介入方式是”AI提案、人决策、AI执行”。
  3. 约束即自由——明确的边界和熔断机制不是限制，而是让AI在擅长领域自由发挥的条件。

五种典型踩坑（跳测试、plan写代码、重复失败、误读意图、过度工程化）在实践中反复出现，每条都有对应的约束策略。记住这些坑，每次协作前检查一次，能避免90% 的AI协作问题。

三条路线中，方案C（边界意识 + 工具化约束 + 熔断机制）是产品级项目最可持续的选择。下一篇我们讨论如何持续改进这套协作——学习、复盘、调整，让协作越来越顺。