# NKBVwPk7MiPg5XksndtcIU7nnWb Source: https://dianchukeji.feishu.cn/wiki/NKBVwPk7MiPg5XksndtcIU7nnWb # 一.工作内容概述 - 服务端问题审查修复、客户端弹窗按钮交互表现优化。 - 结合项目开发历程，进行思考总结。 # 二.人与AI协作中的坐标框架 ## 框架定义 在人与AI协作完成任务过程中，影响最终交付成果质量的，不是AI单方面的能力，而是人与AI在具体任务中的相对位置。 可以用一个二维坐标系来理解： - X轴：人对于当前任务的综合适配度 它不是单纯指“会不会亲手完成”，也不是单纯指“懂不懂技术”，而是指人所具备的所有能力中，有哪些是适配满足这个任务的，适配程度又是多少，比如： - 能不能清晰定义这个任务的需求 - 能不能将这个任务的需求进行合理拆解 - 能不能制定这个任务的方案，或判断这个任务方案的合理性 - 能不能识别风险，解决中途出现的问题，最终验收这个任务 - ...... 越往右，说明人对于这个任务的掌控力越高； 越往左，说明人在这个任务中越依赖于外部，甚至连需求是否合理、交付结果是否可靠都无法判断。 这个位置不是固定的，做自己擅长熟悉的领域时，通常处于右侧，做陌生的领域时通常处于左侧。 - Y轴： AI在当前任务环境下的有效执行能力 不只取决于 AI 模型能力本身，同时也取决于上下文、项目框架、任务结构化程度等等条件。 基于这两个维度，可以把坐标轴分为四个象限： ## 四象限含义定义 ### 右上：杠杆区 右上角是最理想的状态，在这个区域，人的能力能够得到最大限度的放大，： 人知道目标是什么、边界在哪里、什么结果算好、什么风险不能接受；AI 又有能力完成实现、整理、生成、调试等执行工作。 这时 AI 是真正的效率杠杆：人负责定义目标、拆解任务、决策判断、验收结果；AI 负责提高实现速度、减少重复劳动、扩展候选方案和加速迭代。 ### 右下：人主导区 这个区域，通常表现为AI的能力不足，限制了人的发挥，比如定义了明确清晰的需求，AI却无法稳定完成可靠交付的情况。 这种情况还可以接受，因为人对于这个任务，知道什么是对的，也明确知道 AI 错在哪里，只是需要加大人工介入的部分，比如缩小任务范围、进一步拆分任务、给明确约束、补测试、人工审查关键路径等。 这个区域效率不一定最高，但是风险尚处于可控状态。 ### 左下：失控区 这里是最差的状态：人不懂任务，AI 也无法完成可靠交付。继续推进通常只会得到低质量产物，而且人和 AI 都无法稳定判断哪里错了。 ### 左上：视具体情况而定 这里是最值得讨论的区域，这里的状态是：人不完全懂任务，但 AI 看起来能够给出结果。 这在实际项目尤其是单人开发中极其常见，比如不熟悉服务端、数据库，但是通过AI也能够产出一套云存档系统；不熟悉前端业务，通过AI也能够产出一套UI适配逻辑等。 这个区域不能被简单定义为好或者坏，而是得根据具体情况而定。区别不在于 AI 做了什么，而在于人怎么处理 AI 的产出。 ## 左上角区域拆分 左上角的实际定义，完全取决于人在处于左上角时具体做了什么。 人不懂某个领域，但借助 AI 快速进入这个领域，这本身没有问题。真正的问题在于：人拿到 AI 产物之后，是把它当作学习材料，还是直接当作可靠交付。 ### 学习区 比如人拿到 AI 产物之后，会审查、追问、验证和内化，那么左上角可以是很好的学习入口，这个时候AI的产物就不止是结果，还是很好的学习辅助材料。 ### 抽卡区 如果人不懂任务，也不审查、不追问、不内化，只把 AI 的结果直接当成交付，这种情况可以认为：人在需求发出前无法判断需求是否合理、边界是否完整、结果是否可验收，只能等 AI 交付之后，通过运行、测试或反馈来判断这次有没有碰巧命中一个可接受版本。 如果这次刚好能跑，看起来就是成功的。但这不代表人掌握理解了相关业务，只代表这一次 AI 命中了。也就是说，这时候的状态本质上是在“抽卡”。 最危险的情况是：处于左上角而不自知，这时候就会陷入的左上角的“能力陷阱”： - 不懂，却不知道自己不懂； - 产出结果不稳定，却误以为稳定； - 只是 AI 这次恰巧命中结果了，却误以为自己掌控、获取能力提升了。 ### 如何判断自己是否处于左上角 AI 产物进入正式交付前，可以先问自己 6 个问题： 如果多个问题答不上来，就应该默认自己处在左上角。 但这样的方式也有局限。一个人可能会高估自己回答的质量，觉得自己解释清楚了，但其实解释是错的或是不够深入的。 所以自检只能作为初筛，不能作为最终确认。 当任务高风险、自己不确定，或者自检结果模糊时，需要引入外部校验： - 让另一个 AI 做对抗审查，只能作为补充，价值是多一层扰动，帮助发现明显漏洞。 - 请教熟悉该领域的同事； - 对照官方文档、标准教程或成熟方案； ## 框架对于个人全栈开发的应用策略 AI 让个人全栈变得更具可行性，但也更容易制造“虚假的全栈感”。 一个人使用AI，确实可以更快做出产品原型，但问题是：项目看起来是一个人做出来的，不代表这个人真正掌控了所有环节。 很多时候，个人开发者拿到的只是“看起来比较好”的产物。想要提高上限，需要花巨大的时间、精力去试错学习，把自己从坐标系的左上角逐步推向右上角。 但个人的时间和精力始终是有限的，要求自己在所有领域全部右移几乎不可能。因此个人全栈的关键不是“所有东西都懂”，而是：知道哪些左上必须学习，哪些左上可以管理，哪些左上可以快速试错，哪些左上必须找外部兜底。 ### 个人全栈首先要进行“模块规划” 可以把项目拆成多个模块，然后判断自己的能力结合AI，在处理这些模块时，分别处于坐标轴的什么位置上，结合风险进行判断。比如一个小游戏项目，可以这样拆： 模块 能力判断 处理方式 核心玩法逻辑 高适配，掌控能力强 AI 加速实现 云服务 低掌控，高风险 必须重点管理，加强学习理解 美术资源 中等掌控力 AI 辅助，人工验收 UI动效 低掌控，低风险 原型阶段可用AI快速迭代试错 平台审核规则 低掌控 对照官方文档或找外部确认 ... ... ... ### 管理左上角预期时，先看项目目标 如果目标是快速原型、方向探索、内部试错、生成候选方案，那么处在左上角完全可以接受。此时关键不是把它做稳，而是明确它的定位：它是原型，不是最终方案；它可以不完美，但必须可丢弃、可回滚，不能进入长期系统。 如果目标是正式交付、长期维护、进入核心链路，那么左上角就必须被严格管理，至少需要测试、review、外部校验，或者逐步右移。所以左上角是否危险，不只看“人懂不懂”，还要看任务目标是什么。 任务目标 处于左上角时，风险程度 处理方式 快速原型 / 试错 可接受 明确标记为原型，可丢弃，不进入核心系统 学习入门 可接受 用 AI 产物作为学习材料 正式交付 需要谨慎 必须通过自检、测试、review 或借助外部帮助兜底 核心链路 / 长期维护 高风险 必须逐步右移，建立最小掌控力 高风险决策 极高风险 找专家、成熟方案或强验证机制兜底 ### 个人开发中，常见的四类左上 类型 含义 举例 个人开发的应对策略 原型 快速试错、可丢弃、可回滚 HTML单网页原型 可以大胆用 AI，但不能混入正式系统 核心 影响产品主链路和长期维护 核心玩法框架、云服务等 必须逐步学习，向右移动 风险 出错代价高，但不一定要自己完全掌握 广告服务 需要测试、review、成熟方案兜底 工具 工具型、低频、可替换 UI切图工具 可以黑盒使用，但要明确输入输出 个人全栈最重要的不是把所有左上都消灭，而是把有限时间花在最值得掌控的地方。 ### 对核心左上，建立最小掌控力 对核心左上，不要求马上成为专家，但至少要建立最小掌控力。 最小掌控力包括： - 能复述核心流程； - 能解释关键设计选择； - 能列出主要失败场景； - 能设计基本验证方式； - 能修改一个局部功能； - 出问题时知道从哪里开始排查。 可以用五步法向右移动： 另外，“先做再懂”必须有还债窗口。 如果今天用 AI 做出来，明天或本周花时间弄懂，这是合理的。 如果上个月用 AI 做出来，三个月后还没弄懂，却已经在上面继续叠加 AI 生成的代码，这就不是探索，而是技术债累积。 可以按以下约束要求自己： - AI 生成的核心代码，必须在固定时间内完成复盘； - 未理解的模块不能继续叠加复杂功能； - 关键路径必须补注释、补文档、补测试； - 每次 AI 产出都要标记“已理解 / 未理解 / 临时可用”。 ### 个人全栈的真正含义 AI 时代的个人全栈，不是一个人变成全能专家。 更现实的理解是：一个人借助 AI 覆盖完整链路，同时清楚地管理自己的能力缺口。 个人全栈的关键能力不是“什么都亲手做”，而是： - 知道哪些地方必须自己掌控； - 知道哪些地方可以靠 AI 和工具； - 知道哪些地方要找外部兜底； - 知道哪些东西只是原型，不能进入正式系统； - 知道哪些 AI 产物必须复盘、重构和测试。 ## 框架对于团队协作的应用策略 AI 会让团队中每个人的产出能力变强。策划可以更快生成玩法方案，美术可以更快生成风格草图，程序可以更快生成代码和工具脚本。但这也会带来一个新问题：个体的产出效率提升，不代表团队整体效率也得到提升。 如果每个人都用 AI 快速生成内容，但没有统一标准，这些产物可能会出现风格不一致、接口不一致、数据结构不一致、质量标准不一致的问题。最后结果不是效率提升，而是集成成本、沟通成本和返工成本上升。 所以在团队协作里，这套框架的应用重点不是“每个人都往右上移动”，而是：根据项目阶段、产物定位和职责边界，控制 AI 产物如何进入团队协作链路。 ### 原型验证阶段：允许更多左上探索 在原型验证阶段，左上角完全可以接受。因为这个阶段的目标不是稳定交付，而是快速验证想法、创意碰撞、发现问题等。这时即使团队成员对某些领域处于左上，也可以用 AI 快速产出候选方案。 这阶段的原则是： - 可以不稳定，但必须明确它是原型。 - 可以快速产出，但不能默认进入正式开发。 - 可以广泛试错，但要允许丢弃和重做。 也就是说，原型阶段可以放大 AI 的探索价值，但要保留丢弃和重做的权利。 ### 正式开发阶段：必须收敛到统一规范 AI 可以降低生成成本，但不会自动降低协作成本。 如果团队没有统一规范，AI 反而会让每个人都更快地产出一套“只对自己当下有效”的东西，最终增加整体集成难度。 所以正式阶段的原则是：AI 产物不能因为“能跑”就进入正式系统。它必须保证能被团队理解、接入、维护。 ### 进入协作链路前，先标记产物身份 团队中最容易出问题的地方，是原型、临时方案和正式模块之间边界不清。 很多技术债不是一开始就被设计出来的，而是这样产生的： - 原本只是 AI 快速生成的 demo，后来没有重构； - 原本只是临时脚本，后来被反复依赖； - 原本只是验证方案，后来直接进入正式分支。 所以团队需要先明确 AI 产物的身份，一个 AI 产物进入协作链路前，至少要标记它属于哪一类： 产物类型 含义 处理方式 原型产物 用于验证方向、展示效果、碰撞想法 可丢弃，不直接进入正式系统 临时产物 为了解决短期问题或临时流程 要标记清楚，并设置清理或替换计划 候选方案 用于比较不同实现路径 需要评审后才能进入实现 正式模块 会进入长期代码库或核心流程 必须符合规范、测试和 review 要求 这个标记很重要，它不是无谓增加流程，而是为了避免团队误把“AI 快速试出来的东西”当成“已经可以长期维护的东西”。 ### 团队仍然需要传统分工，AI 产物也必须有人负责 AI 会让每个人的能力边界变宽，效率得到提升，但不意味着项目里可以允许每个人随意负责不同部分，然后把 AI 产物一起堆进项目。否则随着项目的迭代，问题只会越来越多，比如： - 临时方案被混入正式系统； - 模块之间互相依赖但没人真正理解全貌； - 出问题后不知道该由谁排查； - ..... 更合理的原则是：AI 产物必须绑定到明确的职责边界里。谁在自己的职责范围内使用 AI，谁就要负责理解、验收、接入和维护对应产物。 如果某个人用 AI 生成了超出自己职责范围的内容，它可以作为候选方案、参考材料或原型，但不能绕过对应负责人直接进入正式系统——AI 可以替你生成，但不能替你承担责任。 因此，以下状态需要避免： - 代码是 AI 写的，所以没人真正理解； - 方案是 AI 给的，所以没人真正负责； 只要一个 AI 产物进入团队项目，就必须明确： - 谁提出需求； - 谁判断方案可行； - 谁负责验收； - 谁负责接入； - 谁负责维护； - 出问题谁来排查； - 它是否允许进入正式分支。 越核心的部分，就越要注意，不能因为 AI 能生成交付，就弱化责任边界。 总结一下，就是：AI 可以扩展个人在职责范围内的产出能力，但不能打散团队原有的责任边界。其产物可以进入项目，但必须由人验收、接入、维护和负责。 ## 总结 人与 AI 协作能力的关键不是“会不会用 AI 生成东西”，而是能不能管理 AI 产物：知道它能用在哪里，不能用在哪里；知道什么时候可以快速试错，什么时候必须严格验证；知道哪些结果可以暂时接受，哪些结果必须复盘、重构和掌控。 真正有价值的，不是把所有事情都交给 AI，也不是所有事情都亲手做，而是在人与 AI 的协作中，持续判断自己的位置，管理自己的能力边界，并把 AI 的执行力转化为可理解、可验证、可维护、可负责的真实生产力。