dc-docs/output/feishu-docs/NKBVwPk7MiPg5XksndtcIU7nnWb.md

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 的执行力转化为可理解、可验证、可维护、可负责的真实生产力。