从一个小需求开始
最近用Codex，我对AI说得最多的一句话是：“我觉得有点复杂。”
有一次，我原本只想解决一个小需求。Codex不断给出更完整的方案，我也一路确认。等我意识到不对时，一个小功能已经被扩展成了要开发一个智能体。
回头看，每一步似乎都有道理：功能更完整，结构更清楚，也为以后留下了扩展空间。
但每一步都合理，不代表叠加起来仍然合理。
这件事让我看到一个很典型的问题：AI执行能力越强，任务负责人越不能只给出一个方向，然后一路确认。
AI不会主动替你做减法
Codex擅长分析、补充、扩展和完善。
它会考虑异常情况，会想到后续使用，也会尝试让方案更加完整。这些能力在复杂项目中很有价值，但在一个边界不清的小需求里，也可能带来过度设计。
它比较容易回答“还可以做什么”，却并不知道“哪些其实不需要做”。
AI也不会主动告诉你：“现在已经够了。”
因为“够不够”不是一个单纯的技术判断，而是目标、收益和复杂度之间的取舍。
一个功能增加以后，可能带来新的规则；新的规则又带来新的数据、接口和维护要求。事情就在一次次“顺便再做一点”中逐步变大。
确认，并不等于判断
那次经历以后，我开始反思：问题并不全在AI，也在于我一路点了确认。
确认只是允许它继续，判断则需要重新回答：
这一项增加，是否还在解决最初的问题？
增加的复杂度，是否值得？
不做这一项，会不会影响当前结果？
如果不会，为什么一定要现在做？
AI可以不断展开可能性，但不能替人决定哪些可能性应该被砍掉。
控制复杂度，要先回答三个问题
过去我们说“把任务说清楚”，通常想到的是把需求描述得更准确。
使用Codex以后，我觉得还要增加一层：不仅要说清楚做什么，还要说清楚不做什么，以及什么时候应该停止。
1，到底要去哪里
首先要明确最终解决什么问题，以及交付到什么程度。
是得到一份分析、完成一个局部功能、做一个小工具，还是建设一个长期运行的系统？
不同目标对应完全不同的投入和复杂度。
目标不只是任务的起点，也应该成为停止扩展的依据。
2，这条路可以走到哪里
还要明确资料范围和执行边界。
哪些资料可以查看，哪些代码可以调整；哪些现有结构不能动，哪些扩展这次先不做。
有些想法可以记录下来，但不需要立即实现。
执行边界不只是安全和权限要求，也是控制复杂度的重要手段。
3，什么时候必须停下来
任务范围扩大、技术架构升级、增加新的模块或依赖时，应该停下来重新判断。
这里的确认不是继续点一次“同意”，而是重新做一次取舍。
最后的验收，也不能看AI完成了多少功能，而要回到最初的问题：它到底有没有被解决。
过去，组织靠人的经验填补任务缺口
在人与人的协作中，很多任务其实也没有被完整定义。
管理者提出一个大致方向后，经验丰富的执行者会根据背景主动补充、控制范围、判断优先级，也会删掉一些没有必要的内容，用较小的投入先解决问题。
这些能力过去常被称为“理解能力”“经验”或者“领会意图”。
换一个角度看，其中很大一部分其实是在替一个模糊任务做范围控制和复杂度管理。
当AI开始承担更多执行工作以后，这部分判断并不会自动消失，而是重新回到了任务负责人手里。
前期对齐，不是增加流程
我以前接触过一种任务沟通方式：安排者先说明任务，执行者再用自己的理解复述，安排者根据复述补充和纠偏，直到双方确认面对的是同一件事。
这里真正重要的不是多说几遍，而是让安排者看见：这项任务到了执行者那里，已经变成了什么。
目标有没有变化，范围有没有扩大，哪些内容被理解成了必须完成，双方对“做完”的标准是否一致。
如果有偏差，可以在开始前及时收回来。
前期对齐不是把事情说复杂，而是避免事情在执行过程中越来越复杂。
AI越能干，人越要知道什么时候停
现在，我再对Codex说“我觉得有点复杂”，已经不只是希望它把方案简化一点。
更多时候，这句话是在提醒我自己：
最初到底要解决什么？
哪些事情这次不做？
做到什么程度已经足够？
AI可以提供方案、完善细节、持续执行，也可以把一个想法扩展成越来越完整的系统。
但复杂度是否必要，是否值得继续，什么时候应该停止，仍然只能由人判断。
AI可以把事情做得更完整，但人必须判断什么才最值得做。
粤ICP备14082021号
免费POC，
零成本试错
