AI 协作工作流

我在产品设计、职业能力梳理和内容制作中持续使用 AI。随着任务从单次生成扩展到多轮交付，问题也从“能否生成”变成：能否沿用正确背景、准确传递需求，并在修改后保持一致。

因此，我先定义使用者要完成的任务及验收标准：产品原型要能检查操作与状态；职业能力梳理要能回到经历证据。AI 承担资料整理、候选方案、生成实现与检查，我负责事实确认、业务取舍和最终采用。

这套方式帮助我减少重复解释背景和从头整理的消耗，也让原本停在文档中的产品判断，能够形成可讨论的静态交互、React 原型和前端页面。

PM Desk 是我探索的产品工作台项目，曾同时存在整体方案、模块原型与历史材料。协作中出现过把模块当成产品主线、将旧结论带入新方案的问题。我据此调整项目记忆：先明确本轮采用什么，再按任务读取所需内容。

项目入口

本轮目标、当前阶段、有效材料和下一步。

先确定从哪里继续

事实与方案

原始依据、已确认规则及其来源；候选和历史材料分别标识。

具体判断回到原文核对

变更与反馈

新事实回到所属材料，变更同步受影响的方案、页面与检查记录。

写回后更新续接入口

在 PM Desk，我将整体主线与模块材料分开管理，并明确哪些只能参考。一个模块完成只更新该模块进度；旧版的评审结论也不代替新版验收。项目入口保存摘要与指针，完整设计仍由对应资产承载。

同样的方法用于职业能力梳理：经历事实、能力判断和对外表达分开维护。新增事实先更新底稿，各用途内容引用同一来源；一轮结束再写回已确认结论与待办，避免几份材料各自变成一套说法。

此前我与 AI 逐步共创产品设计；在 PM Desk，我首次让 AI 承担完整设计，自己负责目标、取舍和验收。多轮修改后，文档采用了新口径，页面仍沿用旧模型。我需要定位失真发生在哪里，让需求能够准确传递到原型。

我选择“任务详情—需求接力”模块试点，把任务状态、AI 整理过程和需求进度分开，分别说明触发条件、结果、失败与返回路径，再逐个核对页面状态。发现规则未定就回到需求补齐；仅表达缺失才修页面，需求变更则沿关系检查受影响的下游。

只需要 PRD 或已有原型的任务，我另设轻量路径，按交付目标保留必要输入和检查，避免简单修改被迫补齐整套设计材料。

整理多年经历时，我希望 AI 帮我识别跨项目可迁移的能力，而不只是概括一段履历。我将这个需求做成“赛博蒸馏”Skill：用具体经历支撑判断，再把结果用于岗位选择、简历表达和面试准备。

先还原经历

围绕背景、任务、行动与结果追问，补出当时的约束、选择和个人作用；不足以判断的地方保留待补证据。

再比较能力

区分本人产出与团队结果，比较不同项目中重复出现的行为；不把单个项目的表现直接扩大为整体能力。

最后支持决策

形成能力图鉴与经历时间线：前者看优势及依据，后者看经历过程；岗位匹配和训练建议继续回到这些事实。

我把输入材料、追问方式、收口条件、输出结构与检查要求写入 Skill。方法负责规定怎样处理，项目记忆保存这个人的经历与进度；换一个使用者时，沿用方法并重新建立其事实材料。

这些结果已成为我整理简历与准备面试的持续依据；模拟与真实面试的反馈，再回到经历、能力判断和训练重点。使用过程中发现的问题，也继续推动追问节奏、归因与呈现方式的修正。

我在使用职业能力梳理 Skill 时，记录 AI 的实际表现、偏差位置与影响。单次内容错误先修产物；反复出现的处理问题，再修改运行规则并加入回归场景。

这轮实践让我把“限制是否足够”改为“任务能否正确完成”：修掉一种错误，也要检查原本正常的流程是否被阻断。后续反馈继续进入版本需求，方法成熟后再扩大采用范围。