chore:文档补全

output/feishu-docs/NKBVwPk7MiPg5XksndtcIU7nnWb.md

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