轻复习

一句话提醒

在时间、开发资源和预算有限时，优先级要说明当前先做什么、为什么能形成核心业务闭环，以及哪些有价值的事项放到后续。

为什么今天看它

• “这些都重要”没有完成排序；优先级是在当前阶段分配有限资源，回答什么先做、什么后做，而不是给需求贴上有价值或没价值的永久标签。
• 实验室资料存档案例中，附件上传加外链访问先形成“资料入库 + 客户可查看”的最小闭环；批量上传有价值，但更偏效率优化，可以后续迭代。

留一个问题

在当前阶段，哪项需求最能解决核心问题并形成最小业务闭环？其他有价值的需求为什么可以后做，排序依据是什么？

参考思路

1. 1.明确当前阶段最核心的问题和要达成的业务结果。
2. 2.列出候选需求，区分闭环必需项与效率、体验等后续优化项。
3. 3.结合用户价值、业务价值和实现成本，判断哪些能力能让核心链路先成立。
4. 4.说明暂缓项仍有价值，只是当前顺序靠后，并写清取舍理由。
5. 5.把优先顺序和依据说清楚；当阶段目标或证据变化时再重新排序。

03_知识库/问题/什么是需求优先级，为什么都重要其实等于没有判断.md

一句话提醒

处理冲突先做诊断：资源冲突谈取舍和交易，标准冲突对齐证据与口径，边界冲突明确流程和控制权，情绪冲突先修复关系再谈事情。

为什么今天看它

• 推进受阻不一定是表达不清，也可能是资源、评价标准、权责边界或旧有情绪造成的协同问题；把所有冲突都当成话术问题会选错处理方式。
• 升级的目标应是裁决优先级、调整资源或明确责任，而不是证明谁对谁错；跨团队协作还要把方案翻译成对方关心的目标、风险与投入。

留一个问题

当前卡点是在争资源、争标准、碰边界，还是有情绪旧账？我需要补什么证据、选项或责任边界，才能让讨论回到可决策的问题？

参考思路

1. 1.先描述冲突事实与各方约束，判断主要属于资源、标准、边界还是情绪冲突。
2. 2.资源冲突谈优先级、投入和可交换条件；标准冲突拿证据并统一评价口径。
3. 3.边界冲突明确流程、决策权、责任和控制权，避免把结构问题归咎于个人。
4. 4.情绪冲突先修复信任、留出安全感，再回到具体事情和可验证事实。
5. 5.确需升级时，说明希望裁决的资源或责任问题，不把升级变成私人审判。

03_知识库/综合/产品经理冲突处理四分法：资源、标准、边界与情绪.md

一句话提醒

记录是收集原始输入、避免遗漏；分析则要整合、分层和判断真实问题及业务价值，最后形成能指导设计与决策的取舍。

为什么今天看它

• 需求清单解决的是信息是否被记录，不会自动说明哪些输入指向同一个问题、哪些只是表层方案，也不能直接给出优先级。
• 这篇笔记把分析落在业务理解上：只有把孤立输入结构化，并判断问题与价值，需求材料才能真正支持后续设计和决策。

留一个问题

我手里的材料只是需求记录，还是已经归并出共同问题、识别表层方案，并说明了业务价值与取舍依据？

参考思路

1. 1.先忠实记录用户输入和发生场景，确保原始信息不丢失。
2. 2.把相关输入归并，标出共同点、差异和需要补充验证的信息。
3. 3.区分用户描述的问题与用户提出的解决方案，判断哪些是真实问题。
4. 4.结合业务目标分析问题背后的价值，而不只统计需求条数。
5. 5.按价值和优先级形成明确取舍，让结论能够指导设计与决策。

03_知识库/问题/为什么记录需求不等于分析需求.md

一句话提醒

AI 更容易接管执行层产出；人的关键价值在于定义问题、理解用户、做方向取舍并承担结果，省下的时间应回流到这些判断工作。

为什么今天看它

• 这篇笔记把产品工作分成执行、判断和价值层：文档与原型等执行产出更容易被自动化，但产出物只是思考的投影，不等于判断本身。
• AI 多数时候在响应已有指令；主动追问更深的问题、理解用户真实意图，并为取舍结果负责，仍是产品经理需要持续练习的能力。

留一个问题

这项工作里，哪些执行产出可以交给 AI？我需要亲自做出的方向判断、用户理解和取舍是什么，如何验证并承担结果？

参考思路

1. 1.把任务拆分为可交给 AI 加速的执行产出，以及需要人做出的判断。
2. 2.先澄清目标与问题，不把 PRD、原型或 Prompt 本身当作最终价值。
3. 3.主动追问用户表述背后的真实意图，并检查是否存在其他达成目标的路径。
4. 4.比较方向与方案，明确取舍依据、边界和不确定性。
5. 5.把 AI 节省的时间投入用户理解、问题定义和结果复盘，并由人承担决策责任。

03_知识库/综合/AI时代产品经理的核心价值.md

一句话提醒

真需求不等于当前最高优先级；还要结合发生频率、平台阶段、资源成本、替代方案和更深层的核心链路判断。

为什么今天看它

• 虚拟电话的案例确实对应私下成交和平台跑单风险，但当时问题发生频率不高，平台仍有更基础的链路问题，因此“需求成立”并不能直接推出“马上优先做”。
• 虚拟电话是一个可能的解法；更深层的问题是平台缺少对撮合后交易链路的承接与控制，先识别问题层级，才能比较解法是否对准根因。

留一个问题

需求成立之后，它的发生频率和影响有多大？结合当前阶段、资源成本、替代方案与更深层链路，它现在是否比其他问题更值得先做？

参考思路

1. 1.先确认问题是否真实存在，并说明它与用户或业务结果的关系。
2. 2.把“需求是否成立”和“当前是否优先”作为两个独立判断。
3. 3.比较发生频率、影响、平台阶段、数据可信度、实施资源和可行替代方案。
4. 4.继续追问表面需求背后的核心问题，区分问题本身与提出的解法。
5. 5.选择符合当前阶段的行动；若根因方案成本过高，可先解决更可行且关键的链路。

03_知识库/问题/如何判断一个需求是真需求但不一定先做.md

一句话提醒

先定义成功标准，再选择最短可行的联网路径；静态方式不足时再升级到登录态浏览器交互，并把反复有效的判断沉淀进 Skill。

为什么今天看它

• 联网任务可能需要搜索、静态抓取或浏览器交互；把 Skill 写成路径选择与结果调整的判断流程，比只记住某个工具命令更可复用。
• 遇到登录态或动态页面时，连接已有浏览器可保留当前会话状态；但应由任务需要决定是否升级，而不是一开始就使用最重的方式。

留一个问题

这项任务的成功标准是什么？搜索或静态抓取能否达到；若不能，是否确实需要登录态或动态页面交互？哪些有效判断值得复用？

参考思路

1. 1.先写清任务目标和可验证的成功标准。
2. 2.根据目标选择最短可行路径，例如搜索、静态抓取或其他现有访问方式。
3. 3.只有静态方式无法完成登录态或动态交互时，再使用连接现有浏览器的路径。
4. 4.根据返回结果调整方法；达到成功标准后停止，不做无目标的重复尝试。
5. 5.把反复验证有效的决策原则沉淀进 Skill，而不只是堆叠命令。

03_知识库/综合/Web Access Skill：给 Agent 装上完整联网能力.md

一句话提醒

真需求成立只说明问题值得解决；当前方案还要看它是否解决核心问题、是否适配阶段、会带来什么副作用以及覆盖范围如何。

为什么今天看它

• 像“改成虚拟电话”这样的表达可能已经是一个解法；直接照做容易漏掉更深层的交易链路问题和其他入口。
• 方案评估需要结合阶段和使用体验，不只看它能否堵住一个表面问题，也要看解决力度、覆盖范围和成本。

留一个问题

这个方案解决了多少核心问题？副作用、阶段适配和覆盖范围怎样？是否存在更合适的路径？

参考思路

1. 1.把真实问题与已经提出的具体做法分开，确认现在讨论的是问题还是方案。
2. 2.回到问题本身，找出核心链路及其他可能入口，避免只堵住最显眼的一处。
3. 3.比较方案的解决力度、副作用、当前阶段适配、覆盖范围和实施维护成本。
4. 4.选择更贴合当前目标与资源的方案，并检查它是否改善核心问题而非只改变表面做法。

03_知识库/问题/如何判断一个方案是不是当前最优解.md

一句话提醒

AI 阅读的目标不只是更快生成摘要，而是让每个重要判断都有来源支撑，并说明证据边界和不确定性。

为什么今天看它

• 来源质量、时效和口径会影响 AI 整理结果；不能把官方材料、专业报道和营销文章默认视为同等证据。
• 引用不等于正确，仍要回到完整上下文核对时间、对象、数字口径和限定条件，并区分事实、推断与待确认。

留一个问题

这个结论来自哪里，来源等级和时效如何，引用上下文是否完整支持？哪些部分是推断或待确认？

参考思路

1. 1.筛选信源并标注来源级别、时间、对象和口径，先判断资料是否适合回答当前问题。
2. 2.按竞品、用户研究、项目或学习主题建立专题资料集，不把无关材料混在一起。
3. 3.提问时写清背景、限制范围、任务、输出格式和证据要求。
4. 4.让 AI 做跨文档比较、差异提取和初步归纳，同时保留来源引用与冲突线索。
5. 5.点回原文核验完整上下文、时间、对象和数字口径，并把结论标为事实、推断或待确认。

03_知识库/综合/来源约束型 AI 阅读工作流：从信息搬运到可追溯判断.md

一句话提醒

Prompt 用来表达这次希望 AI 做什么；Skill 用来固化稳定、可重复的流程，两者处理不同层次的问题，不必二选一。

为什么今天看它

• 把当次任务表达与反复执行的规则分开，能减少知识组织和实际执行方式之间的混淆。
• 流程还不稳定时先用 Prompt 说明需求；当步骤稳定并需要重复复用，再考虑沉淀为 Skill。

留一个问题

我现在是在交代本次任务的目标与边界，还是在固化已经稳定重复的执行流程？

参考思路

1. 1.先判断当前需要表达的是这一次的任务意图、背景和输出要求，还是一套反复发生的工作流程。
2. 2.用 Prompt 说明当次希望 AI 完成什么，以及本次任务的具体要求。
3. 3.只有当流程已经稳定、步骤可复用时，才把它固化成 Skill。
4. 4.把 Prompt 与 Skill 看成分工互补：前者表达当次意图，后者承载稳定流程，不必强行二选一。

03_知识库/问题/个人知识库应该做成 Prompt 还是 Skill.md

一句话提醒

当服务对象会持续变化，首次交付应提供低摩擦、可迭代、可继续优化的底座，并为后续变化留接口，而不是把所有事情一次做满。

为什么今天看它

• 把交付视为生命周期起点，才能继续承接客户在不同阶段的变化，而不是在首次成交后让关系中断。
• 模块化、可替换的初始设计能为后续调整留出空间，让持续服务有实际载体，而不只是一句经营口号。

留一个问题

这次交付面对的对象是否会持续变化？如果会，初版有没有给下一阶段留接口、迭代空间和服务路径？

参考思路

1. 1.先判断对象是一次性问题，还是会随时间、家庭或业务变化持续产生新需求。
2. 2.把首次交付设计成低摩擦、可使用且可调整的底座，避免高成本、不可逆的设计封死后续变化。
3. 3.按生命周期拆分后续阶段，识别每一阶段的变化和对应服务，而不是把长期服务打包成模糊承诺。
4. 4.用案例说明最初为什么这样设计、后来发生了什么变化，以及它如何让升级更容易。
5. 5.评估商业价值时，同时看首次交付与后续关系、复购和长期客户价值。

03_知识库/综合/把一次性交付改成长期关系：家装行业的产品化运营思路.md

一句话提醒

需求滑向方案，就是问题和目标还没澄清，就把某个具体做法当成需求本身；同一个问题往往有多条解决路径。

为什么今天看它

• 过早锁定某个功能或实现方式，会缩小思考范围，让团队把方案误当成需求。
• 真正更合适的解法可能在流程、业务规则或协作方式，而不一定是新增一个功能。

留一个问题

我们现在讨论的是用户或业务问题，还是已经默认了某个做法？如果不采用它，还有哪些路径能达成目标？

参考思路

1. 1.把原始诉求改写成具体用户、场景、问题和期望结果，先不写解决方案。
2. 2.标出表达里的事实、目标和未经验证的实现假设，确认是否把按钮、页面或技术方案误当成需求。
3. 3.围绕同一目标展开多条路径，包含功能改动、流程优化、业务规则和协作调整。
4. 4.再按结果匹配度、成本、约束与风险比较方案，最后决定是否采用最初提出的做法。

03_知识库/问题/什么叫需求滑向方案.md

一句话提醒

企业级 AI 软件不只是接入模型：还要懂企业业务语义、进入实际流程、承载领域 Know-how，并守住权限与审计底线。

为什么今天看它

• 能区分“会听会总结的 AI”与“能给出业务判断并减少一线工作”的企业软件。
• 提醒方案评审不能只看模型效果，还要检查流程整合、隐性经验、权限和责任链。

留一个问题

这个 AI 功能是否对齐业务词典、嵌入一线流程并守住权限与审计？它实际替用户减少了哪些工作？

参考思路

1. 1.检查关键业务词是否有企业自己的定义，AI 是否按明确语义和规则理解，而不是依赖通用猜测。
2. 2.确认 AI 是否进入实际业务流程，能否使用系统表单、校验、审批或记录回写，而非只在外挂聊天框给建议。
3. 3.核对建议是否依赖领域 Know-how，例如业务规则、判断经验、模板和一线打法。
4. 4.明确数据权限、脱敏、人工确认、审计记录和责任归属。
5. 5.最后验证是否真正减少一线工作并改善业务结果，而不是只展示模型能力。

03_知识库/综合/企业级AI软件真正的门槛，不是模型能力，而是业务语义、流程整合与Know-how.md

一句话提醒

伪需求识别先判断一个想法是否值得成为需求候选；需求验证再用频率、影响、稳定性与替代成本，确认它是否强到值得投入。

为什么今天看它

• 避免因为一个想法听起来高级、有人提出或局部有帮助，就跳过场景与价值判断直接做方案。
• 把候选筛查、证据强度确认和后续优先级分开，能区分根本不成立与需求存在但当前不值得投入。

留一个问题

这个诉求有没有通过伪需求筛查？若它是需求候选，频率、影响、稳定性和替代成本的证据够不够？

参考思路

1. 1.先补全业务场景、目标用户和不解决的后果，避免只围绕一个功能名词判断。
2. 2.做第一轮伪需求筛查：追问真实场景和价值，排除只是情绪、表面方案或看起来高级的想法。
3. 3.若它像需求候选，再做第二轮验证：检查发生频率、影响范围、稳定性、业务损失与替代成本。
4. 4.验证需求成立后再排优先级，最后进入方案讨论；需求存在不等于当前就值得投入。

03_知识库/问题/伪需求识别和需求验证有什么区别.md

一句话提醒

AI 更容易替代 PRD、原型和分析等执行型产出；定义问题、理解用户、做取舍并为结果负责，才是更难外包的价值。

为什么今天看它

• AI 会放大已有判断，也会放大模糊；文档和原型是思考的投影，不是思考本身。
• 执行时间被压缩后，应把省下来的时间投入用户理解、问题定义、方向判断和复盘，而不只是继续堆产出。

留一个问题

如果 AI 已经能生成这份 PRD、原型或分析，我真正提供了什么判断、用户理解和结果责任？

参考思路

1. 1.先写清希望用户达成的结果和真实问题，再让 AI 协助执行，不把功能产出误当成问题定义。
2. 2.把工作分成执行产出、判断取舍和价值创造：前者更容易自动化，后两者仍需要人的上下文与责任。
3. 3.用 AI 加速文档、原型和分析，但逐项核验并保留方向选择、用户解释和最终决策权。
4. 4.把释放的时间回流到用户沟通、需求判断、优先级取舍和结果复盘，并对最终结果负责。

03_知识库/综合/AI时代产品经理的核心价值.md

一句话提醒

先判断问题是否真实，再判断它在当前平台阶段、发生频率、资源与核心链路中的优先级；虚拟电话可能只是解法，不是问题本身。

为什么今天看它

• 避免把“需求成立”直接推导成“马上做”，忽略平台阶段、发生频率、资源限制和更根本的链路问题。
• 案例中的虚拟电话可能有助于减少跑单，但平台真正缺的也许是交易链路控制；识别这一层才能避免过早锁定方案。

留一个问题

电话跑单问题确实存在，但以当前频率和平台阶段，先收紧交易链路是否比直接上虚拟电话更根本、更划算？

参考思路

1. 1.先描述用户、业务场景和期望结果，区分真实问题与用户提出的具体做法。
2. 2.验证问题是否存在、发生频率、影响程度和当前证据质量，不因问题真实就直接排到最前。
3. 3.结合平台阶段、资源限制、替代方案和更深层的核心链路，判断当前先做什么。
4. 4.把需求成立、当前优先级和方案选择分开记录；问题与优先级明确后，再比较虚拟电话等具体方案。

03_知识库/问题/如何判断一个需求是真需求但不一定先做.md

一句话提醒

AI 阅读不只是更快生成摘要，而要让重要判断能追到支持它的原文、口径与不确定性。

为什么今天看它

• 避免把 AI 生成的流畅摘要直接当成事实或最终知识，尤其是在竞品、用户研究和项目追溯中。
• 通过限定资料范围、结构化提问和原文核验，把 AI 的机械比较能力转成可供决策的证据链。

留一个问题

这个结论依据哪份来源、原文是否完整支持、时间与对象口径是什么，还有哪些不确定性？

参考思路

1. 1.先筛选并标注来源级别、时间、对象和口径，不默认官方材料、专业报道与营销文章具有相同可信度。
2. 2.按竞品、用户研究、项目或学习主题建立资料集，只把相关材料放在一起。
3. 3.提问时写清背景、限制范围、具体任务、输出格式和证据要求。
4. 4.跨文档比较时标出差异、冲突与变更；关键结论点回原文，检查完整上下文、时间、对象和数字口径。
5. 5.把事实、推断和待确认分开；经过判断的可复用方法再沉淀进知识层，不用摘要覆盖来源原文。

03_知识库/综合/来源约束型 AI 阅读工作流：从信息搬运到可追溯判断.md

一句话提醒

伪需求识别先判断一个想法是否值得成为需求候选；需求验证再用频率、影响、稳定性与替代成本，确认它是否强到值得投入。

为什么今天看它

• 避免因为一个想法听起来高级或有人提出，就直接跳进方案讨论。
• 也避免把需求确实存在误当成现在值得做，让筛查、验证和排优先级分别回答清楚的问题。

留一个问题

我们现在是在筛查需求候选、验证它的证据强度，还是判断它在当前阶段的优先级？

参考思路

1. 1.先说清用户、业务场景、触发时机和期望结果，避免只围绕功能名词讨论。
2. 2.做伪需求筛查：确认场景、价值和真实问题，排除只是情绪、表面方案或看起来高级的想法。
3. 3.若它像一个真实需求候选，再验证发生频率、影响范围、稳定性、业务损失与替代成本。
4. 4.区分需求成立与当前优先级：通过验证后再结合资源、机会成本和阶段目标决定何时做，最后进入方案讨论。

03_知识库/问题/伪需求识别和需求验证有什么区别.md

一句话提醒

AI 数据产品的价值不在答案出现得多快，而在可靠信号出现后，业务能否在结果不可逆前完成有效动作。

为什么今天看它

• 能把实时看板、智能预警等方案从技术速度拉回业务结果，避免把更快直接当成价值。
• 若发现赶不上行动窗口，可以继续定位瓶颈在信号可靠度、诊断路由、审批还是执行，并判断真正该优化哪段链路。

留一个问题

这个场景的可靠信号何时出现、结果何时变得不可逆、动作生效需要多久？

参考思路

1. 1.先写清希望改变的业务结果，以及结果从何时开始基本不可逆。
2. 2.把行动窗口起点设为信号达到可执行可靠度的时刻，而不是第一次出现可疑波动。
3. 3.测量从信号出现到动作生效的完整时长，覆盖识别、诊断、责任路由、决策与执行，并与剩余窗口比较。
4. 4.只有动作能在窗口内生效时，才继续论证实时化或自动化；之后还要验证业务增量，并计入成本与副作用。

03_知识库/综合/AI数据产品的行动窗口：从更快报表到及时干预.md

一句话提醒

记录需求解决信息别遗漏；分析需求还要整合、分层、判断和取舍，才能形成能指导设计与决策的结论。

为什么今天看它

• 逐条保存原始诉求只完成了收集，无法自动看出哪些是真实问题、哪些只是方案表达。
• 把输入整理出结构并结合业务价值判断，才能知道什么值得优先解决，而不只是得到一份更长的需求清单。

留一个问题

这份清单中哪些是原始表达，哪些是背后的问题或方案？它们之间有什么关联，结合业务目标后该如何判断和取舍？

参考思路

1. 1.先完整记录原始需求及上下文，确保信息没有遗漏。
2. 2.将零散输入整合归类，识别重复、关联和共同指向。
3. 3.区分真实问题与表层方案，避免把用户原话直接当作分析结论。
4. 4.结合业务目标理解需求背后的价值，判断哪些问题值得投入。
5. 5.对需求分层、排序并明确取舍，形成能指导设计和决策的结构化结果。

03_知识库/问题/为什么记录需求不等于分析需求.md

一句话提醒

Prompt 用来讲清当前任务；全局配置沉淀跨任务长期有效的身份、沟通偏好、判断原则、红线与工作纪律。

为什么今天看它

• 只靠临时口头交代风格和边界，容易在新任务中遗忘或执行不一致；稳定规则前置后才能跨任务复用。
• 将任务专属要求留在 Prompt、长期规则放进全局配置，能避免反复踩坑，也能让红线和纠偏原则持续生效。

留一个问题

这条要求只服务当前任务，还是需要跨任务长期生效？如果是长期规则，它属于身份、沟通偏好、判断原则、红线、工作纪律还是已犯错误？

参考思路

1. 1.把当前任务的目标、背景、限制和输出格式写在本次 Prompt 中。
2. 2.筛出跨任务稳定有效的协作偏好、原则、红线和工作纪律。
3. 3.按身份、沟通方式、思维原则、红线、工作纪律和已犯错误等模块组织长期规则。
4. 4.明确规则的适用范围与优先级，确保安全边界不会被风格偏好覆盖。
5. 5.交付时检查规则是否被遵守，并在规则失效或重复踩坑时更新配置。

03_知识库/综合/AI 全局配置原则.md

一句话提醒

先确认问题真实存在、稳定发生、影响足够大且当前值得投入；一个真需求也可能只是中等强度，而非最高优先级。

为什么今天看它

• 需求是否成立不能只看有人提出；还要确认具体使用者、业务场景、发生频次、现有替代方式和不解决的影响。
• 真实需求不自动等于最高优先级；若有手工替代且主要改善效率，就需要与核心功能和其他投入比较。

留一个问题

谁在什么场景下遇到这个问题？它多频繁发生，当前如何处理，不解决会造成什么影响？做了之后的价值多大，是否值得当前投入？

参考思路

1. 1.明确目标使用者及其实际业务场景，不停留在抽象功能名词。
2. 2.核实问题发生频次，判断它是稳定问题还是偶发诉求。
3. 3.了解当前替代处理方式及其耗时、错误和遗漏成本。
4. 4.判断不解决的影响与解决后的实际价值，避免只凭“看起来高级”认定需求强。
5. 5.先给需求成立性和强度作判断，再单独与其他需求比较当前优先级。

03_知识库/问题/如何验证一个需求是否真的成立.md

一句话提醒

AI 输出差距往往来自任务信息是否对称；检查目标、背景信息、角色视角和多轮反馈，而不只急着换模型或重写 Prompt。

为什么今天看它

• 输入模糊时，AI 往往给出安全、通用但不贴近具体决策的回答；问题可能在目标、背景、角色或反馈，而不一定是模型能力。
• 把提问当作任务澄清，并通过多轮反馈让 AI 检验漏洞、提出替代路径，比把第一轮结果当终稿更能得到可用输出。

留一个问题

任务目标是否收口？背景、约束和已知信息是否足够？是否给了合适的专业视角？我是否提供反馈并让 AI 检验或反驳当前方案？

参考思路

1. 1.目标层：明确要完成的任务和需要支持的真实决策，避免只描述一个模糊方向。
2. 2.信息层：补齐业务背景、用户特征、时间与资源约束、已有材料和已知事实。
3. 3.角色层：说明希望 AI 从什么专业视角分析，并允许它指出假设或漏洞。
4. 4.输出层：按 CARIO 梳理 Context、Assignment、Role、Information 和 Output。
5. 5.反馈层：把第一轮回答当作起点，通过追问、纠偏、替代方案和验证项持续打磨。

03_知识库/综合/AI 输出质量的四层差距与 CARIO 提问框架.md

一句话提醒

Prompt 用来表达当前要做什么；Skill 用来固化可重复执行的稳定流程，两者不是二选一。

为什么今天看它

• 把 Prompt 和 Skill 当成互斥选项，容易忽略它们承担的职责不同：一个表达意图，一个约束稳定流程。
• 先判断内容要解决的是单次任务表达还是可反复执行的流程，再决定沉淀形式，能避免形式选择脱离实际用途。

留一个问题

这份内容主要是在说明当前任务的目标和意图，还是在规定一套可稳定重复执行的步骤？后续复用时，使用者需要表达什么，又需要按什么流程做？

参考思路

1. 1.先写清这份知识资产要解决的复用问题。
2. 2.如果重点是表达本次任务意图，使用 Prompt 描述目标与要求。
3. 3.如果重点是固化稳定、可重复的执行过程，使用 Skill 承载流程。
4. 4.不要为了二选一而强行统一形式；按意图表达和流程执行的职责组合使用。
5. 5.检查沉淀后的内容是否能被实际调用，并与对应的复用场景匹配。

03_知识库/问题/个人知识库应该做成 Prompt 还是 Skill.md

一句话提醒

先验证真实任务是否有代价，再比较 AI 与普通方案，检查数据工具和权限，最后定义价值评测；条件不成立就回退或暂停。

为什么今天看它

• AI 降低了做 Demo 的成本，也放大了选错问题的代价；能演示不等于解决了真实业务问题。
• 把真实代价、技术匹配、落地条件和价值评测逐关验证，并设置停止或回退条件，可以避免只凭竞品、调用量或生成效果就立项。

留一个问题

用户在具体任务中反复付出了什么代价？AI 是否比规则、搜索或流程改造更合适？数据、工具、权限和人工兜底是否到位？用什么指标证明价值与风险可接受？

参考思路

1. 1.验证是否有人在具体场景中反复付出时间、错误或成本，并记录行为、频次和影响。
2. 2.将 AI 与规则、搜索或流程改造等普通方案对照，确认 AI 对具体任务有额外增益。
3. 3.检查真实数据、工具链、权限边界和人工兜底，确认端到端任务可以落地。
4. 4.预先写出质量、效率、业务、风险和成本等评测与验收标准。
5. 5.只有四道门均有证据支持时才进入最小 POC；不成立时明确停止、回退或先补条件。

03_知识库/综合/AI 需求四道门：先判断值不值得做，再进入 POC.md

一句话提醒

记录需求是避免信息遗漏；分析需求则要整合和分层输入，识别真实问题与表层方案，并结合业务价值做判断和取舍。

为什么今天看它

• 只把原始诉求逐条列成清单，解决的是信息收集，不会自动告诉团队哪些是真问题、哪些只是表层方案。
• 将需求整合、分层并结合业务价值判断，才能把零散输入转化为后续设计和决策真正可用的结论。

留一个问题

这份需求清单里，哪些是原始输入，哪些是背后的真实问题？哪些表达已经带有方案？结合业务目标后，应该优先解决什么、暂缓什么？

参考思路

1. 1.先完整记录原始输入，保留提出者表达与必要上下文，避免信息遗漏。
2. 2.将零散需求整合归类，找出重复、关联和共同指向的问题。
3. 3.区分真实问题、表层方案和单纯的功能表达，不把原话直接等同于分析结论。
4. 4.结合业务目标与价值判断需求的重要性和优先顺序。
5. 5.明确取舍并整理成能指导后续设计与决策的结构化结论。

03_知识库/问题/为什么记录需求不等于分析需求.md

一句话提醒

AI 进入组织后，变化不只在局部流程，也可能重写岗位边界、管理方式和资源分配；要区分真实业务提效与表演式用 AI。

为什么今天看它

• 只关注工具能力或自动化速度，容易漏掉更深层的组织变化，例如管理加码、岗位重新定价和资源重组。
• 公司强调 AI 提效，可能来自真实业务新增量，也可能是旧增长乏力后的组织重组；判断驱动因素，才能看清变化对岗位与协作的影响。

留一个问题

组织推动 AI 是由真实业务新增量驱动，还是旧增长消失后的重组？周报、Skill、token 等管理动作是在改善协作，还是只要求可见的 AI 使用？岗位边界和责任发生了什么变化？

参考思路

1. 1.看到公司 All in AI，先判断它由业务新增量驱动，还是由旧增长消失后的重组驱动。
2. 2.看到 token、Skill、周报或使用埋点等动作，检查它们是在帮助协作，还是制造表演式用 AI。
3. 3.看到岗位合并、全栈化或 Agent 化，判断这是能力升级，还是责任与边界被重新转移。
4. 4.看到裁员与新项目并行，识别组织是在收缩旧业务，还是押注新的增长方向。
5. 5.最后回到业务结果，核对这些变化是否真正创造价值，而不只增加 AI 使用痕迹。

03_知识库/综合/AI 提效进入组织后，先被重写的不是流程，而是岗位和管理逻辑.md

一句话提醒

需求滑向方案，就是问题和目标还没分析清楚，就提前认定某个功能做法；这会遮蔽流程、规则或协作方式等其他解法。

为什么今天看它

• 用户或团队提出的做法只是问题到方案之间的一条路径；过早把它当成需求本身，会让其他可能更优的解法无法进入讨论。
• 真正的解决方式不一定在功能层，也可能来自流程、业务规则或协作方式；先厘清问题与目标，才能有效比较选项。

留一个问题

当前表达描述的是客观问题和目标，还是已经指定了某个功能方案？除了这个做法，流程、业务规则或协作上还有哪些可能路径？

参考思路

1. 1.把原始诉求中的问题、目标和具体做法拆开记录。
2. 2.先确认问题是否真实、影响是什么，以及当前阶段要达成什么结果。
3. 3.暂缓把用户提出的功能直接写成需求结论，避免将实现方式当作问题本身。
4. 4.至少展开不同层级的解决路径，包括功能、流程、业务规则或协作方式。
5. 5.根据目标、约束与影响比较方案，再决定需求范围和实现方式。

03_知识库/问题/什么叫需求滑向方案.md

一句话提醒

Prompt 讲清这次要做什么；全局配置沉淀长期有效的身份、沟通偏好、判断原则、红线与工作纪律。

为什么今天看它

• 每次都靠口头重复偏好和边界，容易遗忘或执行不一致；将稳定规则前置到全局配置，能让协作跨任务延续。
• 将单次任务要求与长期规则分开，能避免配置过度膨胀，也让红线、已犯错误和自检要求更容易被持续遵守。

留一个问题

这条要求只对当前任务有效，还是跨任务长期有效？如果是长期规则，它属于身份、沟通、判断原则、红线、工作纪律还是已犯错误？

参考思路

1. 1.把临时任务目标、背景和交付格式留在当前 Prompt，不直接升级成长期配置。
2. 2.筛出跨任务稳定有效的偏好、原则、红线和工程纪律。
3. 3.按身份、沟通方式、思维原则、红线、工作纪律和已犯错误等模块组织。
4. 4.写清规则的适用范围与优先级，尤其确保安全边界不会被风格偏好覆盖。
5. 5.定期检查规则是否仍然有效，并用交付自检确认它真的改善了协作。

03_知识库/综合/AI 全局配置原则.md

一句话提醒

需求优先级不是否定低优先级需求，而是在有限时间、资源和预算下，先做当前最关键的事，再安排后续。

为什么今天看它

• 当团队说“这些都重要”时，往往还没有明确当前阶段的核心问题，也没有完成先后排序。
• 围绕实验资料存档，先让“资料入库 + 客户可查看”闭环成立，比优先做批量上传更能满足当前目标；后者有价值，但更偏效率优化。

留一个问题

当前阶段最核心的业务问题和最小闭环是什么？哪些能力是让闭环成立的必要条件，哪些只是效率优化，可以排到后续？

参考思路

1. 1.列出需求对应的用户问题与业务目标，不先按提出者声音大小排序。
2. 2.明确当前阶段要先成立的最小业务闭环。
3. 3.比较每项需求对闭环的贡献、用户与业务价值、实现成本和资源占用。
4. 4.把必要能力排在前面，将效率优化或次要能力安排到后续迭代。
5. 5.说明排序依据和阶段边界；低优先级表示晚些做，不等于永远不做。

03_知识库/问题/什么是需求优先级，为什么都重要其实等于没有判断.md

一句话提醒

先说清谁在什么场景下要取什么结果，再倒推内容如何组织和输入；架构先画信息流，不先选技术栈。

为什么今天看它

• 只规划输入和存储、不设计结果如何被取用，系统很容易变成“高级收藏夹”，资料存得进去却无法服务真实任务。
• 把一页纸 MVP 翻译成“取、存、进”的文字架构，能在不陷入技术选型的前提下，让后续实现有清楚的数据流依据。

留一个问题

最终谁会在什么场景下取用什么结果？为了支持这条取用路径，内容应如何分层存储，输入从哪里来、何时触发、是什么格式？

参考思路

1. 1.先写清目标用户、使用场景、取用时机和结果形式，至少设计一条真实的取用路径。
2. 2.从取用目标倒推需要哪些内容、索引和组织层次。
3. 3.定义各存储层的职责，保证原始来源保留且后续加工可追溯、可回退。
4. 4.最后确定输入来源、触发方式与格式，串起完整的数据流。
5. 5.功能只保留 MVP 闭环，同时让架构具备可扩展性；先形成文字架构文档，再考虑具体技术栈。

03_知识库/综合/AI 架构思维：进存取三问.md

一句话提醒

“支持批量上传”只是功能名词；补上谁在什么时候、为了什么以及当前遇到什么痛点，才能判断真正要解决的问题。

为什么今天看它

• 同一句功能需求放在不同人物、时机和目标下，可能代表完全不同的问题；没有场景，就难以判断需求含义与优先级。
• 把原始功能表达补成具体工作情境，可以看清当前流程的成本和风险，避免只按功能名词设计方案。

留一个问题

谁在什么条件下提出这项需求？他要达成什么目标、当前遇到什么痛点？如果不补齐这些场景信息，我们凭什么判断需求含义和优先级？

参考思路

1. 1.从功能名词或原始诉求中识别实际使用者及其角色。
2. 2.补充需求发生的时间、条件和触发情境。
3. 3.明确使用者要完成的目标，以及当前流程卡在哪里。
4. 4.描述现状带来的时间成本、遗漏风险或其他具体影响。
5. 5.把需求改写为“谁在什么场景下，为了什么目标，因为什么痛点，需要怎样的支持”，再评估方案与优先级。

03_知识库/问题/什么是业务场景，为什么脱离场景写需求很危险.md

一句话提醒

先确认真实痛点，再把第一版收敛成 MVP，最后从使用方式倒推输入、存储和输出架构。

为什么今天看它

• 动机、MVP 和架构分别回答“为什么值得做”“第一版做什么”“东西怎么流动”；按顺序收束，能避免从一个大想法直接跳进功能清单或技术实现。
• 架构设计从最终如何使用开始倒推，再决定如何组织和输入资料，能让知识库围绕复用目标搭建，而不是只变成信息仓库。

留一个问题

我现在要做的 AI 系统解决的真实痛点是什么？第一版只做什么、明确不做什么？最终产物如何被使用，输入、分层存储和取用路径是否形成最小闭环？

参考思路

1. 1.从自己高频使用的产品或工作流中，找出真实且反复出现的痛点。
2. 2.明确目标用户、问题、输入、处理、输出，并写出一页纸 MVP。
3. 3.列清第一版暂时不做的范围，避免 MVP 膨胀成功能清单。
4. 4.从最终如何取用和复用结果开始倒推存储分层，再定义输入来源与触发方式。
5. 5.把进、存、取的数据流写清楚，先验证最小闭环，再进入技术实现或扩展。

03_知识库/综合/AI 知识库实战篇 06-08 方法链总览.md

一句话提醒

用户提出需求说明可能存在问题，但不代表其描述就是最优解，也不代表现在值得投入；还要结合业务目标、成本收益、优先级和整体影响判断。

为什么今天看它

• 用户说出口的内容常常已经带有具体方案，而且受其角色和局部视角限制；照单实现可能解决了表面诉求，却错过更合适的解法。
• 需求是否值得做，需要放到整体业务目标中比较收益、成本、资源和优先级，而不能只凭提出者的声音大小决定。

留一个问题

用户原话背后的真实问题是什么？如果照原方案实现，会解决什么、遗漏什么？它带来的整体业务价值是否高于成本和其他优先事项？

参考思路

1. 1.把用户说出的功能或做法，与其希望解决的问题分开记录。
2. 2.结合用户角色和使用场景，判断这项诉求反映的是局部不便还是更广泛的问题。
3. 3.寻找是否存在更能解决根因的方案，不把用户给出的做法当成唯一解。
4. 4.结合业务目标、预期收益、成本、资源和优先级评估整体价值。
5. 5.再决定直接满足、调整方案、继续验证、延后或拒绝，并说明判断依据。

03_知识库/问题/为什么用户提了需求还不够.md

一句话提醒

AI让方案更快做出来，但评审仍要先分清哪些风险可以边跑边补，哪些规则、数据边界和关键异常不能赌。

为什么今天看它

• AI加快了Demo和原型的产出，但速度本身不等于判断充分；先确认这次是演示、灰度还是正式承诺，才能设定合适的质量要求。
• 把质量、时间和机会的冲突，以及风险责任人写清楚，可以避免把不可逆的业务规则、权限边界和关键异常留到上线后补救。

留一个问题

我们现在争的是质量、时间还是机会？这次交付属于Demo、灰度还是正式承诺？哪些风险可以后补，哪些底线不能赌，最后由谁拍板和跟踪？

参考思路

1. 1.先判断本次交付是Demo、灰度还是正式承诺，并据此明确可接受的风险范围。
2. 2.检查核心业务规则、权限与数据边界、关键异常流程，以及可能伤害用户信任的断点。
3. 3.把风险的触发条件、影响范围、严重程度和回滚方式写下来，而不只停留在口头讨论。
4. 4.明确本次范围、决策人、责任人和跟踪人，再判断哪些细节可以边跑边补。
5. 5.用小范围验证尽早暴露问题，并区分可控返工与会形成结构性债务的风险。

03_知识库/综合/AI时代产品评审现场速查卡.md

一句话提醒

Prompt 用于表达这次想让 AI 做什么，Skill 用于把稳定、可重复的处理流程固定下来。

为什么今天看它

• 知识内容和执行流程承担不同作用，分清二者能避免把所有知识都硬塞进一次性提示词或 Skill。
• 是否需要 Skill，取决于同类任务是否重复发生、步骤是否稳定以及输出是否需要一致。

留一个问题

我是在表达当前这次任务的意图，还是已经有一套稳定、重复、值得固定下来的执行流程？

参考思路

1. 1.如果只是说明这一次的目标、背景和要求，用 Prompt 表达当前意图。
2. 2.如果同类任务反复出现，先观察每次重复的稳定步骤和约束。
3. 3.把成熟流程固化为 Skill，让它承载可复用的执行方法。
4. 4.保留 Prompt 对具体任务的灵活表达，不把知识内容和执行流程混成一类。
5. 5.根据实际复用情况迭代 Skill；偶发、尚未稳定的做法先不固化。

03_知识库/问题/个人知识库应该做成 Prompt 还是 Skill.md

一句话提醒

互动叙事要从一次性演示变成持续体验，需要内容可扩展、用户意图能被承接、用户造成的状态变化能在后续保持一致。

为什么今天看它

• 增加生成内容或交互按钮本身不能证明用户有参与感，关键是选择能否产生可见且持续的后果。
• 先明确用户为何回来和需要保留的状态，再验证长时序一致性与单位成本，可以尽早识别产品是否只是漂亮 Demo。

留一个问题

用户为什么会回来？内容供给、开放意图和状态延续分别是否成立？多轮运行后，用户做过的选择还会被世界承认吗？

参考思路

1. 1.先判断产品是世界型、故事型还是角色型，并写清用户回来的理由。
2. 2.分别检查互动内容能否持续供给、产品能否承接非预设意图、用户变化能否延续。
3. 3.为越界或偏离主线的输入设计留在产品世界内部的处理方式。
4. 4.区分永久状态、会话状态和会衰减的状态，并确保后续生成与状态一致。
5. 5.用短时原型、长时多轮测试和单位成本验证体验是否可持续。

03_知识库/综合/AI互动叙事的产品判断：供给、意图与状态三道锁.md

一句话提醒

真需求判断的是问题是否成立，高优先级判断的是已成立的问题在当前阶段排第几。

为什么今天看它

• 有真实场景和稳定痛点，不代表需求必然要现在优先做。
• 先判断成立性，再看资源、收益、替代方案和阶段目标，可以把需求验证与排期取舍分开。

留一个问题

我们已有证据证明这是成立的需求了吗？确认成立之后，它是否比其他需求更符合当前阶段目标和资源条件？

参考思路

1. 1.先通过业务场景、伪需求识别和需求验证判断需求是否真实成立。
2. 2.将“需求成立”与“现在优先做”作为两个不同结论记录。
3. 3.对成立的需求比较收益、资源、替代方案和当前阶段目标。
4. 4.把真需求分为当前先做和后续再做，而不是把后置理解为没有价值。
5. 5.说明排序依据，并在资源或阶段目标变化时重新评估。

03_知识库/问题/真需求和高优先级需求有什么区别.md

一句话提醒

AI 输出差距常来自任务信息不对称；先澄清目标、补足背景、设定角色，再通过多轮反馈打磨结果。

为什么今天看它

• 回答正确却不贴合业务时，问题可能在任务目标或输入背景，而不一定是模型能力。
• CARIO 的价值在于帮助完成任务澄清，让输出能够支持真实决策，而不只是看起来完整。

留一个问题

我是否说清要完成的决策任务、业务背景、AI 的思考视角、已有材料和期望输出？我会如何根据第一轮结果继续反馈？

参考思路

1. 1.明确要解决的真实任务和目标，不只说主题。
2. 2.补充场景、用户、约束、时间和资源等背景信息。
3. 3.指定合适的专业角色或要求 AI 站在反方检验。
4. 4.提供已有材料和信息，并说明证据范围。
5. 5.明确输出格式、深度和验收标准，再通过追问、修正和替代方案持续打磨。

03_知识库/综合/AI 输出质量的四层差距与 CARIO 提问框架.md

一句话提醒

功能回答系统做什么，数据需求回答系统依靠什么信息去做、去记录和去判断。

为什么今天看它

• 页面和按钮很显眼，但其背后的字段定义、指标口径和数据流转更容易在项目早期被漏掉。
• 搜索、报表、推荐和分析能否成立，往往先取决于数据定义是否清楚。

留一个问题

实现这个功能前，所需字段、指标定义、数据来源、记录方式、查看权限和使用维度是否已经明确？

参考思路

1. 1.先区分功能要做什么，以及完成它需要哪些数据。
2. 2.列出必须记录的字段，并统一活跃用户、转化率或有效订单等指标口径。
3. 3.确认数据从哪里来、如何流转、何时记录和如何更新。
4. 4.明确谁能查看数据、按哪些维度使用，以及是否涉及权限边界。
5. 5.再据此设计页面、报表、搜索或推荐，避免功能上线后才发现缺字段或口径不一致。

03_知识库/问题/什么是数据需求，为什么它容易被忽略.md

一句话提醒

有效需求分析要把真实需求从表层说法一路拆到业务问题、验证强度、优先级，再做方案判断和阶段性取舍。

为什么今天看它

• 需求分析不是记住几个孤立概念，而是知道每一步回答什么问题、如何衔接。
• 把需求判断与方案判断分开，能避免把真需求误当成当前最高优先级，或把表层方案直接当作答案。

留一个问题

我现在走到需求分析链条的哪一步？场景、边界、真实性、证据、优先级和方案取舍分别有依据了吗？

参考思路

1. 1.先补齐真实业务场景，并明确本期需求边界。
2. 2.按价值、功能、数据和非功能拆解需求，同时检查是否过早滑向方案。
3. 3.识别伪需求并验证需求是否成立、强度是否足够。
4. 4.在真需求中判断当前优先级，再识别表层诉求背后的深层问题。
5. 5.比较方案的解决力度、副作用和阶段适配性，做出当前取舍。

03_知识库/综合/有效需求分析方法链总览.md

一句话提醒

价值需求回答为什么值得做、要改善什么结果；功能需求回答系统具体要做什么。

为什么今天看它

• 用户说出的按钮、页面和流程往往已经带有方案色彩，直接照做容易错过真正目标。
• 先澄清效率提升、风险降低或结果改善等价值，再判断功能是否是合适的实现方式。

留一个问题

这个功能具体要解决什么问题、改善什么结果？如果去掉按钮或页面的表达，真正的价值目标还说得清吗？

参考思路

1. 1.把用户提出的功能、按钮或页面先记录为功能层表达。
2. 2.追问它为什么值得做，以及谁的什么结果会变好。
3. 3.把价值目标表达成效率提升、时间节省、风险降低或业务结果改善。
4. 4.检查当前功能是否只是其中一种方案，是否还有更合适的解法。
5. 5.再用价值需求校准优先级、验收标准和最终功能范围。

03_知识库/问题/价值需求和功能需求有什么区别.md

一句话提醒

AI 不是替你做产品判断，而是把已经澄清的问题、边界、MVP 和规则更高效地执行出来。

为什么今天看它

• Vibe Coding 的关键不在于让 AI 一口气生成完整产品，而在于把判断层和执行层分开。
• 按调研、追问式 PRD、分阶段原型和规则化 Kickoff 推进，可以减少跑偏和返工。

留一个问题

当前项目的做不做、目标用户、核心痛点、MVP、成功标准和明确不做事项是否已经说清？AI 接下来承担的是执行还是判断？

参考思路

1. 1.先调研现状、用户痛点和可切入的口子，由人做是否值得做的判断。
2. 2.让 AI 一次只追问一个问题，把目标、场景、边界、MVP 和成功标准逐层问清。
3. 3.先确定设计语言和最重要的一页，再以它为基准铺开其他页面。
4. 4.在 Kickoff 前写清项目事实、工作规范、改动分级和不可触碰的边界。
5. 5.每完成一个可运行的小步骤就提交，并保持原型、PRD 和规则同步。

03_知识库/综合/Vibe Coding 的四步工作流.md

一句话提醒

需求边界不是否定扩展价值，而是明确当前阶段解决到哪里、哪些内容暂不解决。

为什么今天看它

• 没有边界，团队很容易在顺手加功能的过程中把一个小问题膨胀成大系统。
• 把暂不做的内容写清楚，才能保护核心问题先完成，并为后续迭代留下判断依据。

留一个问题

这期最核心要解决的问题是什么？哪些功能直接支撑它，哪些虽然有价值但应该明确放到后续？

参考思路

1. 1.先写清本期要解决的核心问题和目标结果。
2. 2.列出本期必须支持的最小场景、资料类型和核心流程。
3. 3.主动写出当前不覆盖的格式、下载、编辑、分类或协同等扩展项。
4. 4.判断每个新增想法是否影响核心闭环，避免用顺手做一下扩大范围。
5. 5.记录后续扩展的重新评估条件，按真实使用习惯逐步放开边界。

03_知识库/问题/什么是需求边界，为什么边界不清需求就会失控.md

一句话提醒

接需求不是把一句功能愿望转给研发，而是先问清背景、目标、场景、范围、规则、验收和风险。

为什么今天看它

• 越早把目标、边界、规则和风险问清楚，后面越少返工、扯皮和责任不清。
• 把需求翻译成可判断的问题，才能为优先级、方案和验收提供依据。

留一个问题

这个需求为什么现在做？谁会变好？具体场景和范围是什么？规则、数据、技术影响、验收标准和风险是否已经说清？

参考思路

1. 1.先问需求从哪里来、当前出了什么问题，以及为什么现在必须做。
2. 2.确认业务价值、用户价值和希望改善的结果或指标。
3. 3.明确使用者、具体场景、前后流程，以及本期做什么和不做什么。
4. 4.继续追问规则、权限、数据口径、异常处理和系统影响。
5. 5.提前对齐交付物、验收方式和风险承担者，避免上线后才发现口径不一致。

03_知识库/综合/接需求十问：把模糊需求翻译成可判断问题.md

一句话提醒

用户需求可以提示问题存在，但不一定给出最优解；是否值得做，还要结合业务目标、成本收益、优先级和整体影响。

为什么今天看它

• 用户看到的是自身角色和局部场景，产品判断还要考虑受影响的人和整体系统。
• 把用户声音与业务判断分开，才能避免把带有方案色彩的诉求直接当成开发结论。

留一个问题

这个需求解决的是谁的什么问题？它是否符合当前业务目标？收益、成本、优先级和整体影响是否支持现在投入？

参考思路

1. 1.先记录用户提出的原始问题和具体场景，不急着接受其中的方案表达。
2. 2.追问用户角色、受影响对象、使用时机和希望改变的结果。
3. 3.把用户价值与业务目标、整体系统影响放在一起比较。
4. 4.评估成本、收益、资源、优先级和不做的代价。
5. 5.再决定现在做、后置验证、调整方案或暂不投入。

03_知识库/问题/为什么用户提了需求还不够.md

一句话提醒

AI 阅读不只是更快生成摘要，而是让每个重要判断都能说明依据来自哪里、是否真的支持，以及还有哪些不确定性。

为什么今天看它

• 来源质量和范围会直接影响 AI 提炼结果，工具本身不能替代信源治理。
• 把事实、推断和待确认分开，才能让知识库沉淀的是可复用判断，而不是漂亮摘要。

留一个问题

这个结论依据的是哪类来源？引用是否完整支持结论？时间、对象、数字口径和限制条件有没有被混在一起？

参考思路

1. 1.先区分官方或一手来源、专业二手来源和待核验材料。
2. 2.按竞品、用户研究、项目或学习主题建立限定资料集。
3. 3.用背景、范围、任务、输出格式和证据要求组织提问。
4. 4.让 AI 做跨文档比较、冲突发现和初步提炼，但保留人的判断。
5. 5.回看引用原文，核对上下文、时间和口径，并标记事实、推断和待确认。

03_知识库/综合/来源约束型 AI 阅读工作流：从信息搬运到可追溯判断.md

一句话提醒

需求优先级不是否定价值，而是在有限资源下判断什么先做、什么后做，让最小业务闭环先成立。

为什么今天看它

• 当时间、开发资源和预算有限时，说“都重要”通常意味着还没有完成真正的排序。
• 用最小业务闭环判断阶段优先级，可以把有价值但不紧急的效率优化放到后续。

留一个问题

当前最核心的业务闭环是什么？哪些功能直接支撑它，哪些只是有价值但可以后置的效率优化？

参考思路

1. 1.先明确当前阶段最核心的问题和业务目标。
2. 2.把候选需求按用户价值、业务价值和实现成本放在一起比较。
3. 3.判断哪些能力能让最小业务闭环先成立。
4. 4.把有价值但不影响当前闭环的功能排到后续迭代。
5. 5.用清晰的先后顺序表达取舍，而不是笼统地说所有需求都重要。

03_知识库/问题/什么是需求优先级，为什么都重要其实等于没有判断.md

一句话提醒

先建立 AI 的概念地图，再分别理解交互、资料检索、任务执行和工具分工，避免一开始被零散名词和榜单带着走。

为什么今天看它

• 概念地图能把零散的 LLM、Prompt、RAG、Agent、Tool 和 MCP 放回同一条学习路径。
• 先理解概念，再选择工具，更容易把 AI 真正接入知识管理和工作流。

留一个问题

我现在缺的是 AI 的底层概念、使用方法，还是工具分工？当前接触的工具是否真的帮助我把概念落到工作流里？

参考思路

1. 1.先用 AI 是什么、如何处理信息、为什么会失忆建立底层直觉。
2. 2.再理解 Prompt、RAG、Agent、Tool 和 MCP 分别解决什么使用问题。
3. 3.把提问、读资料、知识管理和任务执行等场景分别列出来。
4. 4.为每个场景选择合适工具，不让工具清单替代概念理解。
5. 5.把概念和工具接入真实工作流，再继续拆成可复用的概念卡。

03_知识库/综合/AI 入门基础概念地图.md

一句话提醒

记录需求只保证信息不遗漏，分析需求还要整合、分层、判断价值并做出取舍。

为什么今天看它

• 需求清单只是原始输入，不能直接替代设计和决策。
• 把记录和分析区分开，才能避免把表层方案或零散诉求直接当成优先事项。

留一个问题

我现在面对的是一份信息收集结果，还是已经完成了问题整合、价值判断和优先级取舍？

参考思路

1. 1.先把用户提出的原始需求完整记录下来，避免信息遗漏。
2. 2.把孤立需求按问题、场景、目标或对象进行整合分层。
3. 3.区分真实问题、表层方案和只是被提出的想法。
4. 4.结合业务目标重新判断需求背后的价值和影响。
5. 5.根据价值和资源做优先级取舍，让结果能够指导后续设计与决策。

03_知识库/问题/为什么记录需求不等于分析需求.md

一句话提醒

Prompt 解决这次怎么做，Skill 解决以后如何在稳定约束下反复做好。

为什么今天看它

• 把高频任务沉淀成 Skill，可以减少每次重新交代约束的成本。
• 先判断场景是否稳定、结果是否需要一致，再决定是否值得做成长期模板资产。

留一个问题

最近哪些 Prompt 已经反复使用？它们是否需要稳定输出、固定约束和持续迭代，而不是只解决一次任务？

参考思路

1. 1.先确认这个场景是否高频、稳定且值得反复调用。
2. 2.如果同一个 Prompt 已经重复使用三次以上，检查是否每次都在重复交代相同约束。
3. 3.把角色、任务、输出格式和约束收敛成最小 Skill 骨架。
4. 4.为 Skill 增加示例、自检或动态变量，让输出更稳定可测。
5. 5.通过实际使用持续测试和迭代，避免做成无法复用的万能助手。

03_知识库/综合/Skill 设计原则.md

一句话提醒

一个需求被提出、听起来合理，仍不代表值得投入；还要确认真实场景、稳定痛点、使用频率和足够的业务价值。

为什么今天看它

• 先识别伪需求，可以避免把局部帮助或“看起来更高级”的表达直接推进开发，把资源留给真正能支撑当前目标的事情。

留一个问题

这个需求是谁在什么场景下高频使用？不做会影响什么结果？它解决的是稳定痛点，还是只是局部偏好、方案表达或视觉感受？

参考思路

1. 1.先追问具体用户、使用场景、触发时机和当前行为。
2. 2.确认是否存在稳定痛点、足够频率和可观察的影响结果。
3. 3.把“看起来更高级”或“有人提过”与真实业务价值区分开。
4. 4.判断价值是否足以支撑当前的开发、维护和机会成本。
5. 5.将需求降级、验证或驳回，并记录保留问题和重新评估条件。

03_知识库/问题/什么是伪需求，为什么有些需求看起来合理却不值得做.md

一句话提醒

工具选择的核心不是追榜单上的最强模型，而是先看最高频任务，再让轻工具承担轻任务、强工具承担高价值任务。

为什么今天看它

• AI 工具会不断变化，但按任务场景、输出要求和成本分层的选型逻辑更稳定；先建立组合，再决定是否更换单点工具。

留一个问题

我最高频的任务是什么？哪些任务值得使用强模型，哪些可以交给免费或轻量工具？当前组合是否比只追一个“最强工具”更划算？

参考思路

1. 1.先列出最高频任务，并区分查询、整理、分析、写作、编程和多模态等场景。
2. 2.为每类任务明确速度、质量、上下文、资料处理和执行能力要求。
3. 3.把高价值、低频且需要稳定判断的任务分配给强工具。
4. 4.把高频、基础、可容错的任务分配给免费或轻量工具。
5. 5.定期复盘工具组合的实际效果和成本，不被榜单或单次体验牵着走。

03_知识库/综合/AI 工具选择原则.md

一句话提醒

用户需求能提示问题存在，但可能带着局部视角和方案色彩；是否值得做，还要结合业务目标、ROI、优先级和资源判断。

为什么今天看它

• 如果把用户提出的功能直接当成决策结论，团队容易只优化局部体验，却忽略整体业务目标、投入成本和其他用户的影响。

留一个问题

用户说出的是真正的问题还是已经包装好的方案？它对整体业务目标的价值、成本收益、优先级和系统影响分别是什么？

参考思路

1. 1.先把用户提出的功能或做法还原成具体场景和要解决的问题。
2. 2.区分用户的局部角色视角与产品、业务或系统整体目标。
3. 3.比较该需求带来的用户价值、业务价值、投入成本和预期收益。
4. 4.结合当前优先级、资源和其他用户的影响判断是否值得现在做。
5. 5.如果不直接采纳，说明保留的问题、替代方案和后续验证方式。

03_知识库/问题/为什么用户提了需求还不够.md

一句话提醒

Agent 不是更强的聊天框，而是由模型、规划、记忆和工具共同组成的执行系统；产品判断要落到每一层的边界和失败处理。

为什么今天看它

• 只看模型能力容易把 Agent 产品理解得过于简单；把四个模块拆开，才能判断它如何思考、记忆、行动，以及做错后如何回退。

留一个问题

这个 Agent 是边做边想还是先想后做？它该记住什么、能调用哪些工具、哪些动作需要用户确认，出错后如何重试或降级？

参考思路

1. 1.先明确模型负责的理解、生成和推理边界，以及输出稳定性要求。
2. 2.根据任务特点选择边做边想或先想后做的规划方式。
3. 3.区分短期状态、长期记忆和不应保留的噪声，明确记忆保留周期。
4. 4.定义工具的调用条件、权限边界、异常处理和必须确认的外部动作。
5. 5.为失败设计重试、降级、用户提示或人工确认路径，再验证完整闭环。

03_知识库/综合/拆解AI Agent四件套：模型、规划、记忆与工具的产品视角.md

一句话提醒

需求边界不是否定其他价值，而是明确这次解决到哪里、哪些内容当前不做，避免“顺手加一下”把核心问题膨胀成大系统。

为什么今天看它

• 边界没有写清时，扩展能力会不断挤占核心问题的资源；先锁定最常用场景和最小流程，才能让版本真正落地。

留一个问题

本期要完成的核心问题和最小流程是什么？哪些功能当前明确不做，它们的重开条件是什么？

参考思路

1. 1.先明确当前版本要解决的核心问题与目标用户场景。
2. 2.写出本期必须完成的最小流程和最常用的支持范围。
3. 3.列出容易被“顺手加入”的扩展能力，并明确它们当前不在范围内。
4. 4.说明后置能力不是没有价值，而是应在核心流程验证后再进入迭代。
5. 5.为暂不做项保留重开条件，例如真实使用频率、业务风险或闭环验证结果。

03_知识库/问题/什么是需求边界，为什么边界不清需求就会失控.md

一句话提醒

Prompt 解决这次怎么做；当场景高频重复、约束反复交代且结果需要稳定时，应升级为可测试、可迭代的 Skill。

为什么今天看它

• 把一次性指令与长期复用流程分开，才能让模板库成为真正可调用的资产，而不是不断堆积的提示词文档。

留一个问题

这个 Prompt 是否已反复使用、总在重复交代相同约束，且需要稳定输出？如果是，它的角色、任务、输出格式和约束分别是什么？

参考思路

1. 1.先确认场景是否高频重复，并判断结果是否需要稳定一致。
2. 2.为 Skill 保持单一具体任务，避免做成覆盖一切的万能助手。
3. 3.写清角色、任务、输出格式和约束这四个最小模块。
4. 4.把反复出现的示例、动态变量和自检要求补进实际需要的位置。
5. 5.用真实任务测试并迭代，确认它比临时 Prompt 更稳定后再长期沉淀。

03_知识库/综合/Skill 设计原则.md

一句话提醒

优先级不是否定需求价值，而是在时间、开发资源和预算有限时，明确什么先做、什么后做。

为什么今天看它

• “都重要”会让团队无法形成行动顺序；把需求放回当前阶段的核心问题和最小业务闭环，才能让资源先解决最关键的事。

留一个问题

当前阶段最核心的问题和最小业务闭环是什么？哪些能力必须先做才能闭环，哪些虽有价值但更偏后续效率优化？

参考思路

1. 1.先写清当前阶段要解决的核心问题和成功标准。
2. 2.列出候选需求，并区分它们是闭环能力、风险控制还是效率优化。
3. 3.判断每项需求不做会不会阻断最小业务闭环。
4. 4.在用户价值、业务价值和实现成本之间比较，明确本期先后顺序。
5. 5.把后置但仍有价值的需求写成后续迭代项，避免被误解为永久不做。

03_知识库/问题/什么是需求优先级，为什么都重要其实等于没有判断.md

一句话提醒

AI 接管执行后，人的价值转到定义问题、拆解任务、设置约束、判断方案、验收结果并对最终交付负责。

为什么今天看它

• AI 生成会减少可见的亲手痕迹，但不会减少产品判断和交付责任；保留这些判断的证据，才能让协作价值被看见、被复盘。

留一个问题

这项 AI 协作成果里，我定义了什么问题和成功标准？设置了哪些边界？做了什么选择和验收？最终责任由谁承担？

参考思路

1. 1.先说明目标、对象、成功标准和交付范围，避免只把任务交给 AI。
2. 2.把大任务拆成可执行步骤，并补齐必要上下文和依赖关系。
3. 3.明确业务规则、权限、风险和不可触碰的边界。
4. 4.比较候选结果与方案，记录取舍理由，不把生成结果直接当成最终答案。
5. 5.用验收标准、人工复核、版本记录和异常回滚确认可交付性及责任边界。

03_知识库/综合/AI时代的成果认领与责任边界：从亲手执行到人机协作.md

一句话提醒

功能回答做什么，数据需求回答靠什么信息去做、去记录和判断；页面做出来不等于数据口径已经成立。

为什么今天看它

• 报表、搜索、推荐和分析等功能，最终都依赖字段、指标口径、数据来源、流转方式和访问权限；越早明确这些，越能避免后期返工。

留一个问题

这个功能依赖哪些字段和指标？每个数据的定义、来源、流转、记录方式、展示维度和访问权限是否已经明确？

参考思路

1. 1.先把功能目标拆成需要记录、查询、统计或判断的数据。
2. 2.为每个关键字段和指标写清业务定义、口径、单位和时间范围。
3. 3.确认数据从哪里产生、经过哪些流程流转，以及在哪个节点被记录。
4. 4.明确数据如何展示和使用，包括维度、粒度、更新频率和访问权限。
5. 5.在开发前检查数据定义能否支撑真实业务判断，避免先做页面再补数据。

03_知识库/问题/什么是数据需求，为什么它容易被忽略.md

一句话提醒

企业 AI Coding 不该从买哪款工具开始，而要先看自研能力和数据准备度，再选择低风险、可回滚的任务逐级扩大。

为什么今天看它

• 如果跳过企业阶段、数据边界和质量机制，AI 工具很容易从提效尝试变成不可控的研发风险；先定位再试点，才能知道 AI 应该做到哪里为止。

留一个问题

这个团队当前的自研能力和数据准备度处在哪一阶段？第一个低风险、可回滚、可衡量的 AI 试点是什么？谁负责 Review、测试和回滚？

参考思路

1. 1.先判断企业自研占比、技术栈控制力和代码、接口文档、测试用例的数据准备度。
2. 2.根据阶段选择业务提效、独立小模块、任务级协作或研发流程路由，不要一开始就跳级替代。
3. 3.为首个试点选择低风险、可回滚、可衡量的任务，并明确人机协作边界。
4. 4.先划定公开可用、内部脱敏和绝对不可用的数据边界，再让 AI 接触最小必要数据集。
5. 5.用代码 Review、测试、回归、灰度和异常追溯验证稳定性，出现稳定信号后再扩大范围。

03_知识库/综合/企业AI Coding落地路径：先定位阶段，再决定工具与协作.md

一句话提醒

一个方案能解决问题，不代表它就是当前最优；还要比较解决力度、副作用、阶段适配、覆盖范围和成本。

为什么今天看它

• 真实需求只说明问题值得解决，方案还要结合平台阶段、资源和体验约束，选择当前最合适的路径。

留一个问题

这个方案解决了多少核心问题？它的副作用、阶段适配、覆盖范围和成本，是否值得现在上线？

参考思路

1. 1.先把表面功能还原成真正要解决的深层问题，避免把方案当需求。
2. 2.至少列出一个轻量方案和一个更彻底的流程或链路方案。
3. 3.比较各方案的解决力度、副作用、覆盖范围、开发成本和维护成本。
4. 4.结合平台阶段、资源条件、问题频率和用户体验判断适配性。
5. 5.选择当前最值得先上的方案，并保留后续升级或回滚路径。

03_知识库/问题/如何判断一个方案是不是当前最优解.md

一句话提醒

AI 短片难点不是生成一个镜头，而是让角色、画风、叙事和动作在多个镜头中保持一致；先固定资产，再逐镜生成和验收。

为什么今天看它

• 一次生成整条视频很容易把局部问题放大成整片返工；把角色、分镜和单镜生成拆开，才能低成本校准和回滚。

留一个问题

你要做的这条 AI 视频，受众和表达目标是什么？角色/画风基线、分镜顺序、每镜验收标准分别是什么？

参考思路

1. 1.先明确受众、故事目标和看完后希望用户理解或完成的动作。
2. 2.固定角色外形、穿搭、发型、光影、环境和产品界面的视觉基线。
3. 3.用静态分镜先校准构图、动作、情绪和镜头顺序。
4. 4.每个镜头独立生成、筛选和重试，把问题限制在可回滚单元内。
5. 5.最后合成并验收角色/界面一致性、信息清晰度、版权、品牌和事实风险。

03_知识库/综合/AI短片制作工作流：先控制一致性，再逐镜生成.md

一句话提醒

数据需求不只是页面展示结果，而是提前定义系统要记录什么、如何定义、从哪里来、怎么流转以及谁能使用。

为什么今天看它

• 页面、按钮和流程很显眼，数据定义却容易被推迟；一旦字段口径、来源和权限不清，报表、搜索、推荐和判断都会失真。

留一个问题

这个功能依赖哪些字段和指标？每个数据如何定义、从哪里来、如何记录和流转，谁能按什么维度查看？

参考思路

1. 1.先区分功能要完成的动作与支撑动作所需的数据。
2. 2.逐项定义字段、指标和业务口径，避免‘活跃用户’等词各自理解。
3. 3.确认数据来源、采集方式、记录时机和流转路径。
4. 4.明确数据如何统计、展示和被后续功能或业务判断使用。
5. 5.前置检查数据权限、质量和可追溯性，再进入页面和功能设计。

03_知识库/问题/什么是数据需求，为什么它容易被忽略.md

一句话提醒

产品设计不是把想法做成页面，而是依次确认值不值得做、影响到哪里、用户如何完成任务，以及如何证明完成并能止损。

为什么今天看它

• AI 让页面和方案生成得更快，但也更容易跳过价值、影响面、异常恢复和上线止损；用四层判断链能把‘做出来’重新拉回‘做对并可控’。

留一个问题

这次需求的价值证据是什么？它会影响谁的权限、数据和流程？正常与失败路径如何完成，什么可观察结果才算完成？

参考思路

1. 1.先用行为数据、访谈、工单或可复现任务确认事情是否值得做，并说清机会成本。
2. 2.界定范围与影响面，检查权限、存量用户、旧数据、合规安全和上下游契约。
3. 3.围绕用户任务设计正常、无权限、超时、部分失败和可恢复路径。
4. 4.在设计阶段写清行为结果、正负场景、兼容性和质量底线。
5. 5.提前定义指标、暂停条件、回退责任和数据恢复方式，形成可止损闭环。

03_知识库/综合/产品设计四层判断：价值、边界、体验与验收.md

一句话提醒

需求真实且方向重要，不代表当前最该先做；还要结合发生频率、平台阶段、资源限制和更深层链路做取舍。

为什么今天看它

• 产品讨论容易把真实风险直接等同于最高优先级；把‘是不是问题’和‘现在排第几’拆开，才能先补最根本、最值得投入的链路。

留一个问题

这个需求是真问题吗？它现在发生得多频繁、有没有替代方案、平台处于什么阶段，以及是否还有更根本的链路应该先补？

参考思路

1. 1.先确认问题是否真实存在，并明确它影响的业务目标或平台收益链。
2. 2.检查发生频率、影响强度和当前是否仍有可接受的替代方案。
3. 3.结合平台阶段、数据质量、资源限制和实施成本判断当前适配度。
4. 4.把表面功能解法还原成更深层的业务链路问题。
5. 5.分别回答‘是不是需求’和‘现在排第几’，再决定做、延后或先补基础链路。

03_知识库/问题/如何判断一个需求是真需求但不一定先做.md

一句话提醒

AI 加速的是文档、原型和代码产出，真正需要人判断的仍是场景、风险、优先级和谁来承担后果。

为什么今天看它

• AI 让‘先做出来’变得更容易，也更容易把核心规则、权限、异常和信任风险包装成以后再改的问题；产品判断要先分清哪些能快跑，哪些不能乱跑。

留一个问题

这个需求可以先跑的是 Demo、灰度还是正式承诺？哪些细节能后补，哪些核心规则、数据权限和异常流程不能晚想？

参考思路

1. 1.先明确这次快跑是在做 Demo、灰度验证还是正式承诺。
2. 2.把需求评估拆成验证速度、质量底线和组织判断三个维度。
3. 3.允许文案、样式和次级路径边跑边补，但前置确认核心规则、权限、数据和关键异常。
4. 4.结构化记录风险的触发条件、影响范围、概率和建议处理方式。
5. 5.确认谁参与拍板、谁拥有控制权、谁承担上线后的后果。

03_知识库/综合/AI时代的产品三角困局：验证速度、质量底线与组织判断.md

一句话提醒

真实工作里没有总是最优的方案；当前更值得先上的，往往是轻量、可落地、可控且对体验扰动较小的方案。

为什么今天看它

• 方案讨论容易默认选择最彻底的解法，但早期产品更需要在解决力度、副作用、实施成本和平台阶段之间做现实取舍。

留一个问题

哪个方案理论上更彻底，哪个方案更适合当前阶段？它们的解决力度、副作用、成本和体验影响分别是什么？

参考思路

1. 1.先把表面功能还原成真正要控制或改善的深层问题。
2. 2.至少比较一个轻量方案和一个更彻底的流程或链路方案。
3. 3.分别评估解决力度、副作用、开发成本、影响范围和用户理解成本。
4. 4.结合平台阶段、资源限制和问题发生频率判断当前适配度。
5. 5.先选择轻量、可落地、可回滚的阶段性方案，并保留后续升级路径。

03_知识库/问题/如何在不完美方案里做阶段性取舍.md

一句话提醒

AI 时代不只是要能做出来，更要先把真实用户、具体场景、最小闭环和成功标准说清楚。

为什么今天看它

• AI 会更快把模糊要求实现成一个看起来能跑的东西；先收束问题定义，才能避免实现速度放大方向偏差。

留一个问题

真实用户是谁、具体场景是什么、第一版要验证哪个最小闭环？什么结果算做对，哪些边界不能踩？

参考思路

1. 1.先明确真实用户、具体场景和当前最主要的痛点。
2. 2.把想法翻译成第一版要改善的目标，而不是直接罗列功能。
3. 3.只保留能验证核心痛点的最小闭环，避免第一版越做越大。
4. 4.让 AI 先追问用户、边界和成功标准，再进入实现阶段。
5. 5.提前写清验收标准、失败条件和不能触碰的边界。

03_知识库/综合/AI时代最稀缺的不是做页面，而是把问题定义清楚.md

一句话提醒

需求真实且方向重要，不代表当前最该先做；还要结合发生频率、平台阶段、资源限制和更深层链路做取舍。

为什么今天看它

• 产品讨论容易把真实风险直接等同于最高优先级；把‘是不是问题’和‘现在排第几’拆开，才能先补最根本、最值得投入的链路。

留一个问题

这个需求是真问题吗？它现在发生得多频繁、有没有替代方案、平台处于什么阶段，以及是否还有更根本的链路应该先补？

参考思路

1. 1.先确认问题是否真实存在，并明确它影响的业务目标或平台收益链。
2. 2.检查发生频率、影响强度和当前是否仍有可接受的替代方案。
3. 3.结合平台阶段、数据质量、资源限制和实施成本判断当前适配度。
4. 4.把表面功能解法还原成更深层的业务链路问题。
5. 5.分别回答‘是不是需求’和‘现在排第几’，再决定做、延后或先补基础链路。

03_知识库/问题/如何判断一个需求是真需求但不一定先做.md

一句话提醒

AI 加速的是文档、原型和代码产出，真正需要人判断的仍是场景、风险、优先级和谁来承担后果。

为什么今天看它

• AI 让‘先做出来’变得更容易，也更容易把核心规则、权限、异常和信任风险包装成以后再改的问题；产品判断要先分清哪些能快跑，哪些不能乱跑。

留一个问题

这个需求可以先跑的是 Demo、灰度还是正式承诺？哪些细节能后补，哪些核心规则、数据权限和异常流程不能晚想？

参考思路

1. 1.先明确这次快跑是在做 Demo、灰度验证还是正式承诺。
2. 2.把需求评估拆成验证速度、质量底线和组织判断三个维度。
3. 3.允许文案、样式和次级路径边跑边补，但前置确认核心规则、权限、数据和关键异常。
4. 4.结构化记录风险的触发条件、影响范围、概率和建议处理方式。
5. 5.确认谁参与拍板、谁拥有控制权、谁承担上线后的后果。

03_知识库/综合/AI时代的产品三角困局：验证速度、质量底线与组织判断.md

一句话提醒

需求验证先回答它是否真实、稳定、影响足够大且值得投入，不要一上来讨论功能怎么实现。

为什么今天看它

• 一个用户或团队提出的功能，只说明有人表达了诉求；把角色、场景、频次、替代方案和不做的影响问清，才能区分真需求与高优先级需求。

留一个问题

这个需求给谁用、在什么场景发生、多久发生一次？如果不做会有什么影响，做了又带来多大价值？

参考思路

1. 1.先确认目标用户和需求发生的真实业务场景。
2. 2.检查问题是否稳定发生，以及当前是如何被替代处理的。
3. 3.评估不做的影响，区分真实痛点与轻微不便。
4. 4.评估做成后的价值，并与实现成本和其他机会比较。
5. 5.先判断需求是否成立、强度如何，再单独判断它当前排第几。

03_知识库/问题/如何验证一个需求是否真的成立.md

一句话提醒

AI 阅读的目标不是更快生成摘要，而是让每个重要判断都能说清依据来自哪里、是否真的支持以及还有什么不确定。

为什么今天看它

• 当 AI 可以快速整理大量资料时，真正容易出错的是来源混用、口径错配和把推断当事实；先约束来源，再核验结论，才能让阅读结果用于决策。

留一个问题

你今天要让 AI 分析的材料，哪些是一手信源？问题范围、输出格式和证据要求是否已经写清？关键结论回看原文了吗？

参考思路

1. 1.先区分官方、一手、专业二手和待核验材料，标注时间、对象和口径。
2. 2.按竞品、用户研究或项目主题建立边界清晰的专题资料集。
3. 3.用‘背景 + 限制范围 + 任务 + 输出格式 + 证据要求’组织提问。
4. 4.让 AI 做跨文档比较和初步提炼，但保留对来源级别、商业含义和优先级的人工判断。
5. 5.回到原文核对完整上下文、时间和限定条件，并标记事实、推断和待确认状态。

03_知识库/综合/来源约束型 AI 阅读工作流：从信息搬运到可追溯判断.md

一句话提醒

需求边界既要说清这次解决到哪里，也要说清当前不解决什么；它不是否定价值，而是保护核心问题先被解决。

为什么今天看它

• 需求很容易在‘顺手做一下’中不断膨胀；把当前范围和暂不处理项写清，才能让团队围绕核心问题收敛。

留一个问题

这次需求要解决到哪里？哪些内容虽然有价值，但基于当前阶段、资源和核心问题，明确暂时不做？

参考思路

1. 1.先明确这次真正要解决的核心问题和目标结果。
2. 2.写出当前版本必须覆盖的最小范围，避免从功能名词直接扩张成系统。
3. 3.把下载、编辑、分类、协同等扩展项列为明确的暂不解决内容。
4. 4.检查每个新增想法是否服务当前目标，拒绝以‘顺手做一下’进入范围。
5. 5.根据真实使用反馈和阶段变化，按版本逐步重新打开边界。

03_知识库/问题/什么是需求边界，为什么边界不清需求就会失控.md

一句话提醒

设计体系不只是颜色和字体，而是把项目气质、首屏感知、信息层级、明确不要什么以及组件约束固定下来。

为什么今天看它

• 页面持续迭代时，如果气质、信息层级和组件判断没有被沉淀，每次改动都会重新争论；把设计方法和项目答案写下来，才能稳定复用。

留一个问题

这个项目希望用户打开时先感受到什么？页面任务、信息层级、明确不要什么，以及颜色、排版和组件约束分别是什么？

参考思路

1. 1.先判断项目是否有持续页面、品牌和交互迭代，再决定是否需要独立设计体系。
2. 2.用设计方法层明确页面任务、受众、气质和信息层级。
3. 3.参考成熟样本，理解设计令牌和组件约束可以细化到什么程度。
4. 4.把方法层和样本层收束成当前项目真正采用的专属答案。
5. 5.将最终判断落到页面、颜色、排版、间距和组件规则，而不是停在抽象形容词。

03_知识库/综合/项目设计体系文档：从视觉气质到组件约束.md

一句话提醒

还没确认问题和目标就跳到功能解法，会把实现方式误当需求，遮蔽更优路径。

为什么今天看它

• 产品讨论容易把第一种可行做法直接当成答案；先拆开问题层、目标层和方案层，才能保留替代路径和判断空间。

留一个问题

你现在讨论的“需求”是在描述谁的什么问题，还是已经偷偷指定了某个功能解法？

参考思路

1. 1.先说清楚谁在什么场景下遇到什么问题，不要一开始就命名功能。
2. 2.确认问题背后的目标和约束，避免把表面诉求当成完整需求。
3. 3.至少列出两条可能的解决路径，防止把第一种做法当成唯一答案。
4. 4.检查当前表达是否把实现方式误写成需求本身。
5. 5.比较流程、业务规则、协作方式和产品功能等不同层级的解法，再决定是否进入具体设计。

03_知识库/问题/什么叫需求滑向方案.md

一句话提醒

Agent 联网不只是搜索或抓取，而是根据目标在搜索、抓取、浏览器交互和经验复用之间做正确切换。

为什么今天看它

• 面对登录态、动态页面和交互任务时，单一抓取工具很容易反复试错；把联网拆成调度、执行和经验层，才能稳定复用。

留一个问题

面对一个需要联网的任务，成功标准是什么？你应该先搜索、直接抓取，还是升级到带登录态的浏览器交互？

参考思路

1. 1.先定义联网任务的成功标准，不为了形式上的完整而多做动作。
2. 2.根据目标选择最可能直达结果的路径，优先使用轻量方式。
3. 3.静态抓取遇到登录态、动态渲染或交互限制时，再升级到浏览器层。
4. 4.每一步都用实际结果校正路径，达到目标后及时停止。
5. 5.记录域名、页面和操作经验，让下一次同类任务可以复用而不是从零试错。

03_知识库/综合/Web Access Skill：给 Agent 装上完整联网能力.md

一句话提醒

需求验证先回答它是否真实、稳定、足够重要且值得投入，不要一上来讨论功能怎么实现。

为什么今天看它

• 用户或团队提出一个功能，只说明有人表达了诉求；把真实场景、使用频次、替代方案和不做的影响问清，才能判断需求强度和优先级。

留一个问题

这个需求给谁用、在什么场景发生、多久发生一次？如果不做会有什么影响，做了又带来多大价值？

参考思路

1. 1.先确认目标用户和需求发生的真实业务场景。
2. 2.检查问题是否稳定发生，以及当前是如何被替代处理的。
3. 3.评估不做的影响，区分真实痛点与轻微不便。
4. 4.评估做成后的价值，并与实现成本和其他机会比较。
5. 5.先判断需求是否成立、强度如何，再单独判断它当前排第几。

03_知识库/问题/如何验证一个需求是否真的成立.md

一句话提醒

企业 AI Coding 不该从买哪款工具开始，而要先判断自研能力、数据准备度和可安全进入的任务层级。

为什么今天看它

• 企业 AI 项目容易先讨论 Cursor、Copilot 等工具，却忽略任务边界、数据边界、验收和回滚机制；先定位阶段，才能找到低风险的真实试点。

留一个问题

你面对的团队处在哪个 AI Coding 阶段？第一个低风险、可回滚、可衡量的试点任务是什么？

参考思路

1. 1.先判断团队的自研占比、技术栈控制力和数据准备度。
2. 2.根据团队阶段选择业务提效、小模块开发、任务协作或流程路由层级。
3. 3.优先挑选低风险、可回滚、可衡量的任务做试点。
4. 4.为代码、接口文档、测试用例和业务数据划分可用、脱敏和不可用边界。
5. 5.用 Review、测试、回归和灰度验证每一级，再决定是否扩大 AI 的任务范围。

03_知识库/综合/企业AI Coding落地路径：先定位阶段，再决定工具与协作.md

一句话提醒

用户提出需求能提示问题存在，但不等于给出了最优解；是否值得做还要看业务目标、成本收益和整体影响。

为什么今天看它

• 需求讨论容易把用户表达直接升级成待办事项；把用户声音与业务判断分开，才能避免局部诉求绑架整体决策。

留一个问题

这个用户需求代表的是谁的什么问题？它对业务目标的贡献、成本收益、优先级和系统影响分别是什么？

参考思路

1. 1.先把用户提出的内容当作问题信号，不直接当成方案或立项结论。
2. 2.确认提出者的角色、场景和视角，识别其中可能带有的方案色彩。
3. 3.判断该需求是否服务当前业务目标，而不只看是否有人提出。
4. 4.比较预期价值、实施成本、覆盖范围和机会成本，估算投入产出。
5. 5.结合整体系统影响和当前优先级决定做、延后、改造或拒绝。

03_知识库/问题/为什么用户提了需求还不够.md

一句话提醒

自己搭 AI 知识库不是为了多存资料，而是让信息经过加工、连接和回写，变成能长期复用的个人能力。

为什么今天看它

• 当资料越积越多却不一定越懂时，要把知识库从存储工具升级为能编译、连接、回写和支持产出的个人产品。

留一个问题

你今天新增的这条资料要解决哪个具体问题？它会更新哪条旧知识，或支持哪项后续输出？

参考思路

1. 1.先明确知识库要替自己解决的真实问题，不先追求功能完整。
2. 2.把原始资料编译成结构化笔记，而不是只留下收藏或存档。
3. 3.新资料进入后检查它要连接和更新哪些已有主题。
4. 4.用索引、双链和回写让知识网持续生长，而不是不断新增孤立页面。
5. 5.根据自己的问答、研究、复盘或写作目标设计入口，不直接照搬别人的方案。

03_知识库/综合/AI 知识库为什么要自己搭.md

一句话提醒

还没确认问题和目标就跳到功能解法，会把实现方式误当需求，遮蔽更优路径。

为什么今天看它

• 产品讨论常把第一种可行做法直接当成答案；先拆开问题层、目标层和方案层，才能保留替代路径和判断空间。

留一个问题

你现在讨论的“需求”是在描述谁的什么问题，还是已经偷偷指定了某个功能解法？

参考思路

1. 1.先说清楚谁在什么场景下遇到什么问题，不要一开始就命名功能。
2. 2.确认问题背后的目标和约束，避免把表面诉求当成完整需求。
3. 3.至少列出两条可能的解决路径，防止把第一种做法当成唯一答案。
4. 4.检查当前表达是否把实现方式误写成需求本身。
5. 5.比较流程、业务规则、协作方式和产品功能等不同层级的解法，再决定是否进入具体设计。

03_知识库/问题/什么叫需求滑向方案.md

一句话提醒

终端 AI 时代，产品不一定靠最强模型赢；掌握系统调度、权限与交互入口，同样能掌握主动权。

为什么今天看它

• 分析 AI 产品时，容易被新功能和模型能力带偏；把视角拉到系统调度、权限和交互入口，才能看清产品真正争夺的层级。

留一个问题

如果你分析一个 AI 产品，它掌握的是模型能力，还是系统调度和用户入口？它能否形成新的产品范式？

参考思路

1. 1.先判断产品是在争模型能力，还是在争系统调度、权限和交互入口。
2. 2.把显眼的新功能与底层性能、稳定性和老设备兼容分开评估。
3. 3.分析 AI 是否真正嵌入系统工作流，而不是只叠加在单点功能上。
4. 4.遇到本地化或上线争议时，拆成能力层、架构层和监管层分别判断。
5. 5.比较不同终端形态的交互潜力，确认 AI 是否正在改变默认交互方式。

03_知识库/综合/WWDC2026 复盘：苹果在 AI 范式与系统底层之间的取舍.md

一句话提醒

真需求成立只说明问题值得解决，方案还要比较解决力度、副作用、阶段适配、覆盖范围和成本。

为什么今天看它

• 需求讨论很容易把提出的方案直接当成答案。把问题层、方案层和当前阶段拆开，才能避免只堵一个表面入口，却伤害体验或错过更根本的链路。

留一个问题

你当前考虑的方案解决了多少核心问题？它的副作用、阶段适配、覆盖范围和成本是否值得现在上线？

参考思路

1. 1.先确认要解决的深层问题，避免把表面功能当成完整需求。
2. 2.评估方案对核心问题的实际解决力度，而不只看是否能工作。
3. 3.检查对用户体验、流程和现有系统的副作用。
4. 4.结合平台阶段、资源条件、覆盖范围和实施成本判断适配性。
5. 5.在多个方案之间做比较，选择当前最值得先上的路径，并保留升级空间。

03_知识库/问题/如何判断一个方案是不是当前最优解.md

一句话提醒

AI 能施工不等于可以放任它一次做完；先喂产品、架构和选型图纸，再小步推进、逐步验证和及时返工。

为什么今天看它

• 当 AI Coding 让做出 Demo 变得容易时，真正决定能否扛住生产的是前置上下文、任务拆分、每步验收和局部止损，而不是一句大而全的指令。

留一个问题

你准备让 AI 开始做的一个功能，三份图纸是什么？能否拆成一个个可单独运行和验收的小任务？

参考思路

1. 1.先准备产品定义、架构和技术选型三份图纸，减少 AI 猜目标和边界。
2. 2.一次只派一个小任务，先跑通入口或最小闭环。
3. 3.每完成一步就运行和验证一步，不把问题累积到最后。
4. 4.遇到报错保留原始信息，让 AI 针对局部问题返工。
5. 5.高频、机械且稳定的动作再沉淀成脚本，避免一开始过度程序化。

03_知识库/综合/Agentic Coding 四步法：从图纸到可运行结果.md

一句话提醒

伪需求识别判断它是否值得认真对待，需求验证判断它是否强到值得现在投入。

为什么今天看它

• 团队容易把所有诉求直接带入方案讨论。先做第一轮伪需求筛查，再用频率、影响、稳定性和替代成本验证强度，可以减少对表面合理需求的过度投入。

留一个问题

你手上的一个需求，是从根上就不成立，还是确实存在但证据还不够强？下一步应是排除，还是补充验证？

参考思路

1. 1.先看业务场景、价值和提出者的真实问题。
2. 2.做伪需求识别，检查它是否只是情绪、方案偏好或看起来高级。
3. 3.若有成立可能，再验证发生频率、影响范围、稳定性和业务损失。
4. 4.比较替代成本与当前投入价值，判断需求强度而不只判断存在与否。
5. 5.验证通过后再进入优先级排序和方案讨论。

03_知识库/问题/伪需求识别和需求验证有什么区别.md

一句话提醒

AI 时代团队升级不只是多一个工具，而是从承接需求、串行交接转向发现机会、做关键决策和并行验证。

为什么今天看它

• 如果 AI 只是让文档写得更快，团队的运行方式并没有改变。真正的升级是把团队目标切到业务价值，减少信息衰减，并提高验证和纠错的密度。

留一个问题

你当前的团队是在承接和转写需求，还是在验证业务假设？哪些工作可以从串行交接改成围绕结果的并行验证？

参考思路

1. 1.把团队交付物从文档和流程节点重新对齐到业务结果。
2. 2.先找信息量大、结构重复、交接容易失真的高频环节。
3. 3.明确当前要验证的业务假设、关键指标和错误代价。
4. 4.让产品、研发、设计和业务围绕同一结果并行推进，而不是逐棒传递。
5. 5.用验证速度、错误方向识别和结果改善衡量团队价值，而不只看文档数量。

03_知识库/综合/AI驱动的产品团队：从需求承接到业务价值放大.md

一句话提醒

需求真实且重要，不代表它就是当前最该做的，还要看平台阶段、频率、资源、替代方案和更深层链路。

为什么今天看它

• 团队容易把真实问题直接等同于立即开发。先区分问题是否成立、当前是否值得投入和表面解法是否触及根因，才能做出阶段性取舍。

留一个问题

你当前面对的一个需求，真实问题、表面解法和更深层链路分别是什么？如果暂不做，最应该先补哪项基础能力？

参考思路

1. 1.确认问题真实存在，并核对发生频率、影响范围和业务损失。
2. 2.把用户提出的功能解法与平台真正要控制的深层问题分开。
3. 3.结合平台阶段、资源限制、替代方案和基础链路判断优先级。
4. 4.识别更根本但当前投入过重的方案，避免把理论最优当成立即路径。
5. 5.选择当前能收住关键风险的阶段性行动，并保留后续升级路线。

03_知识库/问题/如何判断一个需求是真需求但不一定先做.md

一句话提醒

长期事实放规则，可复用流程放 Skill，确定性护栏交给脚本或权限，复杂噪声任务再做隔离。

为什么今天看它

• 当全局配置越来越长，或模型反复漏掉关键检查时，问题通常不是继续堆 Prompt，而是把事实、流程、护栏和独立任务放到各自可靠的机制里。

留一个问题

你准备新增的一条规则或自动动作，究竟属于长期事实、可复用流程、必须确定执行的护栏，还是应该隔离的高噪声任务？

参考思路

1. 1.长期稳定的项目事实、边界和协作原则放入全局或项目规则。
2. 2.只在特定任务触发的重复步骤固化为 Skill、模板或工作流。
3. 3.绝对不能出错的检查交给脚本、权限、校验或 Hook，不依赖模型记忆。
4. 4.搜索量大、日志长且可独立验收的过程放入 Subagent 或独立任务。
5. 5.多路并行且需要交叉验证时再使用工作流编排，避免无证据过度加机制。

03_知识库/综合/Agent上下文分层：事实、流程、护栏与隔离执行.md

一句话提醒

功能回答做什么，数据需求回答靠什么信息去做、去记录、去判断。

为什么今天看它

• 产品讨论很容易先看到页面、按钮和流程，但报表、搜索、推荐和运营判断能否成立，往往取决于字段、口径、来源、流转和权限是否先被定义。

留一个问题

你正在设计的一个功能，依赖哪些数据字段和指标口径？这些数据从哪里来、谁能看、最终支持什么判断？

参考思路

1. 1.先明确功能要支持的业务判断或行动，而不是只描述页面结果。
2. 2.列出需要记录的字段、事件、状态和时间维度。
3. 3.统一指标定义，明确数据来源、计算口径和更新频率。
4. 4.梳理数据如何流转、展示和被不同角色使用，并补上权限边界。
5. 5.在功能开发前确认数据是否可采集、可验证、可持续维护。

03_知识库/问题/什么是数据需求，为什么它容易被忽略.md

一句话提醒

AI 项目要先验证真实代价、技术匹配、落地条件和价值评测，再决定是否进入 POC。

为什么今天看它

• AI 降低了做 Demo 的成本，也放大了选错问题的成本。用四道门设置退出条件，可以避免把会生成内容的界面误当成解决业务问题的产品。

留一个问题

你当前考虑的 AI 需求卡在哪道门：真实代价、技术匹配、落地条件，还是价值评测？最少还缺哪条证据？

参考思路

1. 1.真实代价：确认用户在具体场景里反复付出什么时间、错误或成本。
2. 2.技术匹配：比较 AI 与规则、搜索或流程改造的实际增益。
3. 3.落地条件：核对数据、工具、权限和人工兜底是否到位。
4. 4.价值评测：提前写清质量、效率、业务、风险和成本指标。
5. 5.四道门通过后再做最小 POC，不成立就停止或回退补证据。

03_知识库/综合/AI 需求四道门：先判断值不值得做，再进入 POC.md

一句话提醒

有人提出、听起来合理或局部有帮助，都不足以证明一个需求值得当前投入。

为什么今天看它

• 面对‘做出来看起来更高级’这类诉求时，先追问使用者、场景、频率、痛点和不做的损失，才能区分低优先级真需求与当前阶段的伪需求。

留一个问题

你正在考虑的一条需求，真实使用场景、发生频率、稳定痛点和业务价值分别是什么？如果说不清，是否还不该进入开发？

参考思路

1. 1.确认是谁在什么场景下使用，以及具体要完成什么任务。
2. 2.追问痛点是否稳定发生，频率和影响是否足够明确。
3. 3.拆掉‘看起来更高级’等感受性表达，寻找可验证的业务结果。
4. 4.判断不做会造成什么损失，并与开发成本和替代方案比较。
5. 5.证据不足时先降级、补验证或驳回，不要因为有人提出就直接立项。

03_知识库/问题/什么是伪需求，为什么有些需求看起来合理却不值得做.md

一句话提醒

Prompt 解决这一轮怎么做，全局配置解决长期如何协作、哪些事不能越界。

为什么今天看它

• 当同一个错误反复出现，或每次新对话都要重讲沟通方式和边界时，问题不是再写一条临时指令，而是把稳定规则沉淀进长期生效的配置文件。

留一个问题

你最近还在反复口头提醒 AI 的哪条规则？它是否已经稳定到应该写入 AGENTS、项目规则或其他长期配置？

参考思路

1. 1.把关于身份、沟通方式和工作偏好的稳定内容集中记录。
2. 2.把必须先问的红线与不可越界的边界单独写清。
3. 3.补充改动、验证、自检和交付等工程纪律。
4. 4.把已经发生过的错误转化为可执行的长期约束。
5. 5.区分一次性任务 Prompt 与跨任务长期生效的配置，避免两边混用。

03_知识库/综合/AI 全局配置原则.md

一句话提醒

还没把问题和目标分析清楚，就跳到具体功能，会把实现方式误当成需求本身。

为什么今天看它

• 面对‘加一个功能’或‘改一个按钮’的表达时，先把问题层和解法层拆开，才能看见流程、规则或协作方式等其他可能路径。

留一个问题

你正在讨论的一条需求，描述的是用户要解决的问题，还是已经预设了某个功能解法？还有哪些不同路径没有被比较？

参考思路

1. 1.先明确用户、场景、目标和当前真正受阻的环节。
2. 2.标记原始表达中已经带有的功能、流程或技术方案。
3. 3.把问题层与解法层分开，避免直接把方案当成需求。
4. 4.至少列出功能、流程、规则或协作方式等不同解决路径。
5. 5.比较各路径对目标、成本、边界和后续链路的影响后再定方案。

03_知识库/问题/什么叫需求滑向方案.md

一句话提醒

AI 输出的差距常来自目标、信息、角色和反馈的不对称，而不只是模型能力差距。

为什么今天看它

• 当 AI 给出正确但无用的答案时，先检查目标是否明确、背景约束是否充分、角色视角是否合适，以及是否进行了多轮反馈，再考虑换模型或重写 Prompt。

留一个问题

你最近一次得到泛泛 AI 回答时，真正缺的是目标、背景信息、专业视角，还是第二轮反馈？

参考思路

1. 1.Context：说明你是谁、处于什么业务场景和当前问题。
2. 2.Assignment：写清要完成的任务，以及最终要支持的判断。
3. 3.Role：指定 AI 采用的专业视角，必要时让它扮演反对者。
4. 4.Information：补齐已有材料、约束、已知结论和不能碰的边界。
5. 5.Output：规定格式与深度，并把第一轮结果当作后续追问的起点。

03_知识库/综合/AI 输出质量的四层差距与 CARIO 提问框架.md

一句话提醒

伪需求识别判断它是否值得认真对待，需求验证判断它是否强到值得现在投入。

为什么今天看它

• 团队容易把所有需求都直接带入方案讨论。先做第一轮伪需求筛查，再用频率、影响、稳定性和替代成本验证强度，可以减少对表面合理诉求的过度投入。

留一个问题

你手上的一个需求，是从根上就不成立，还是确实存在但证据还不够强？下一步应是排除，还是补充验证？

参考思路

1. 1.先看业务场景、价值和提出者的真实问题。
2. 2.做伪需求识别，检查它是否只是情绪、方案偏好或看起来高级。
3. 3.若有成立可能，再验证发生频率、影响范围、稳定性和业务损失。
4. 4.比较替代成本与当前投入价值，判断需求强度而非只判断存在与否。
5. 5.验证通过后再进入优先级排序和方案讨论。

03_知识库/问题/伪需求识别和需求验证有什么区别.md

一句话提醒

复杂波动往往不是单点事件，而是交易、信贷和债务在反馈回路与时间延迟下累积出的阶段性结果。

为什么今天看它

• 遇到宏观变化或复杂业务问题时，先找最小单位、放大器、反馈回路和杠杆点，比只追逐表面新闻或单个结果更容易看清系统如何运转。

留一个问题

你正在观察的一个业务波动，最小交易单位是什么？什么变量在放大它，什么延迟或累积会让问题晚于原因出现？

参考思路

1. 1.先把复杂现象拆回可观察的最小交易或行为单元。
2. 2.识别支出、收入、信贷等变量之间的反馈关系。
3. 3.区分短期放大器与长期累积变量，不把一次波动当成全部原因。
4. 4.标记时间延迟、债务或负担的累积，以及可能触发转折的阈值。
5. 5.寻找利率、资源配置、规则调整或结构变化等可干预的杠杆点。

03_知识库/综合/经济机器是怎样运行的：用交易、信贷与债务周期理解宏观波动.md

一句话提醒

Prompt 适合表达这次想让 AI 做什么，Skill 适合把稳定、高频、可复用的做法固化下来。

为什么今天看它

• 不是所有知识都值得做成 Skill，也不是所有工作流都应该每次临时写 Prompt。把一次性意图与稳定流程分开，能减少过度固化，也能让高频协作真正资产化。

留一个问题

你最近反复写的一段 Prompt，是临时任务说明，还是已经具备稳定输入、输出和检查标准，值得升级成 Skill？

参考思路

1. 1.先判断这次需求是一次性表达意图，还是重复出现的稳定场景。
2. 2.一次性任务优先保留为 Prompt，明确目标、背景、输出与限制。
3. 3.高频且结果需要稳定的任务，再提炼角色、流程、约束和自检。
4. 4.为 Skill 写清输入、输出、边界和验证方式，避免只保存一段口号。
5. 5.定期根据真实使用反馈迭代 Skill，未稳定前不要过早固化。

03_知识库/问题/个人知识库应该做成 Prompt 还是 Skill.md

一句话提醒

框架库的价值不只是收集更多框架，而是让你按问题类型、适用阶段和杠杆强度快速找到该用什么。

为什么今天看它

• 面对大量方法和框架时，平铺收藏只会增加检索成本。先保留站点级索引，再拆出高频、适合当前工作的框架节点，才能真正支持研究、方案和问题拆解。

留一个问题

你最近遇到的问题属于用户洞察、问题定义、系统分析还是方案生成？现有知识库能否让你快速定位一个可用框架？

参考思路

1. 1.先把外部框架站点作为来源对象整体保存，保留它的地图和组织方式。
2. 2.按问题类型、适用阶段和杠杆强度建立导航维度。
3. 3.优先拆分与你当前工作高频相关的框架，而不是一次性搬运全部内容。
4. 4.为每个框架保留解决问题、结构、适用场景、案例和误区等固定骨架。
5. 5.持续把常用框架沉淀成独立知识节点，并回链到主题入口。

03_知识库/综合/PMFrame.works 产品设计框架库.md

一句话提醒

功能回答做什么，数据需求回答靠什么信息去做、去记录、去判断。

为什么今天看它

• 产品讨论很容易先看到页面、按钮和流程，但报表、搜索、推荐和运营判断能否成立，往往取决于字段、口径、来源、流转和权限是否先被定义。

留一个问题

你正在设计的一个功能，依赖哪些数据字段和指标口径？这些数据从哪里来、谁能看、最终支持什么判断？

参考思路

1. 1.先明确功能要支持的业务判断或行动，而不是只描述页面结果。
2. 2.列出需要记录的字段、事件、状态和时间维度。
3. 3.统一指标定义，明确数据来源、计算口径和更新频率。
4. 4.梳理数据如何流转、展示和被不同角色使用，并补上权限边界。
5. 5.在功能开发前确认数据是否可采集、可验证、可持续维护。

03_知识库/问题/什么是数据需求，为什么它容易被忽略.md

一句话提醒

代码是阶段性产物，业务、规则、产品和交付上下文才是能持续复用的长期资产。

为什么今天看它

• 当 AI Coding 让实现越来越快时，真正决定结果质量的是你是否把目标、边界、规则、验收、异常和反馈组织成下一轮可复用的上下文。

留一个问题

你最近一个 AI 项目只留下了哪些代码？如果要让下一次协作更准，还缺哪类业务、规则、产品或交付上下文？

参考思路

1. 1.补齐业务上下文：需求为什么存在，谁在什么场景下使用。
2. 2.补齐规则上下文：状态如何流转，异常如何兜底，哪些边界不能碰。
3. 3.补齐产品上下文：角色如何进入，页面如何组织，交互如何反馈。
4. 4.补齐交付上下文：权限、部署、安全、培训和维护由谁负责。
5. 5.把真实试用中暴露的缺口与修正记录下来，回写到长期项目文档。

03_知识库/综合/AI Coding时代，产品经理真正的核心资产是上下文.md

一句话提醒

用户需求能提示问题存在，但是否值得做仍要结合业务目标、成本收益、优先级和整体影响。

为什么今天看它

• 用户提出的内容常已带有具体方案，也受其角色视角限制。直接照做会把局部最优误当整体最优；需求分析要把声音翻译为问题，再做业务取舍。

留一个问题

你正在接收的一条用户需求中，用户真正遇到的问题是什么？原话里的方案成分、局部视角和业务约束分别是什么？

参考思路

1. 1.先记录用户原话与使用场景，确认它提示的真实问题。
2. 2.拆出其中已经预设的功能或解决方案，不把它直接当需求本体。
3. 3.比较局部角色收益与整体系统、其他角色和长期目标的影响。
4. 4.评估成本、预期收益、资源占用与当前优先级。
5. 5.形成业务判断：做、暂缓、拒绝或换一种更合适的解法。

03_知识库/问题/为什么用户提了需求还不够.md

一句话提醒

知识库的价值不在收藏更多原文，而在把原文编译成结构化条目，并让新信息持续更新旧判断。

为什么今天看它

• 当资料越来越多时，检索只能帮你找回内容，不能替你形成判断。把原始来源、结构化知识、规则与索引分层，才能让已有结论被后续材料不断校正和复用。

留一个问题

你最近保存的一条资料，应该沉淀成哪一条结构化结论？它又需要回写或修正哪一篇已有笔记？

参考思路

1. 1.把原始资料保留在来源层，避免直接把收藏当作知识。
2. 2.提炼可复用的结构化条目，明确它回答的问题或结论。
3. 3.用 schema 约束字段、流程和组织方式，减少随意堆放。
4. 4.补充索引与相关链接，让条目能从全库入口被找到。
5. 5.新资料进入时先检查它是否会补强、修正或淘汰旧结论。

03_知识库/综合/Karpathy 的个人知识库方法.md

一句话提醒

需求真实且重要，不等于它就是当前最该做的；还要看频率、平台阶段、资源与更深层链路。

为什么今天看它

• 面对具体解法时，团队容易直接讨论怎么做。先拆开“问题是否存在”“表面解法是否触及根因”“当前是否值得投入”，能避免把有限资源压在阶段不对的方案上。

留一个问题

你当前的一个需求，真实问题与提出的解法分别是什么？如果暂不做，平台更根本的链路问题是哪一条？

参考思路

1. 1.确认问题是否真实存在、发生频率是否稳定、影响是否足够大。
2. 2.把用户提出的功能解法与平台真正想控制的深层问题分开。
3. 3.结合平台阶段、资源限制、替代方案和基础链路判断当前优先级。
4. 4.识别更根本但暂时过重的投入，避免把理想路径误当立即路径。
5. 5.选择本阶段能收住关键链路的行动，并说明暂不做的原因。

03_知识库/问题/如何判断一个需求是真需求但不一定先做.md

一句话提醒

AI 产品的基本单位不是一次生成，而是能被验证、可控出错、值得再次托付的任务结果。

为什么今天看它

• 评审 AI 功能时，若只确认模型能生成内容，很容易停在 Demo。先定义任务完成标准、确认点与失败接管，才能判断它是否真的替用户把事办成。

留一个问题

你正在推进的一个 AI 功能，用户最终要完成的任务是什么？系统如何验证完成，并在什么节点必须由人确认？

参考思路

1. 1.先写清使用者、受影响者与高价值任务，而不是先列模型能力。
2. 2.定义可观察的完成标准、任务频率和所需上下文。
3. 3.区分自动生成、自动推荐、人工确认与直接阻断的边界。
4. 4.在授权后执行，并以真实状态验证结果，不以模型自述替代验证。
5. 5.记录异常、返工与人工接管，持续看任务完成率和重复托付率。

03_知识库/综合/AI产品的结果交付闭环：从能力展示到持续托付.md

一句话提醒

不完美方案的取舍不是默认选最彻底的，而是选当前阶段更轻、更快、更可控的解。

为什么今天看它

• 面对风险或体验问题时，团队容易直接追求根治方案。先比较副作用、落地性与解决力度，才能避免把未来更适合的重方案过早压到当前阶段。

留一个问题

你当前正在比较的方案里，哪一个更彻底，哪一个更适合当前资源、链路成熟度和体验约束？两者是否被混成同一个判断？

参考思路

1. 1.先明确要控制的深层问题，而不是只复述表面功能诉求。
2. 2.列出不同路径分别是在做功能限制、流程限制还是更底层的机制调整。
3. 3.比较每条路径对体验、流程和现有系统的副作用。
4. 4.评估开发成本、改动范围、时间与当前资源条件。
5. 5.结合解决力度与平台阶段，选择当前最适合先上的方案，并保留后续升级路径。

03_知识库/问题/如何在不完美方案里做阶段性取舍.md

一句话提醒

AI 输出的差距常在信息对称：目标、背景、角色和反馈都要先补齐。

为什么今天看它

• 当 AI 给出正确但无用的泛泛答案时，优先检查目标、信息、角色和反馈哪一层没收口，而不是立刻换模型或重开对话。

留一个问题

你最近一次觉得 AI 回答空泛的任务，缺的是目标、背景约束、专业视角，还是第二轮反馈？

参考思路

1. 1.Context：说明你所处的业务场景与当前问题。
2. 2.Assignment：写清这次要完成的具体任务与判断目标。
3. 3.Role：指定 AI 应采用的专业视角，必要时让它扮演反对者。
4. 4.Information：补齐已有材料、约束、已知结论和不能碰的边界。
5. 5.Output：规定输出格式，并把第一轮结果当作后续追问的起点。

03_知识库/综合/AI 输出质量的四层差距与 CARIO 提问框架.md

一句话提醒

需求边界明确这次做到哪里、暂时不做什么，目的是保护当前阶段聚焦核心问题。

为什么今天看它

• “顺手加一下”的扩展最容易让最小需求膨胀成大系统。写清本期不做什么，才能让范围、资源和后续版本保持一致。

留一个问题

你正在推进的一项需求，能否明确写出本期做到哪里、暂不做什么，以及哪些扩展只是当前阶段不必要而非没有价值？

参考思路

1. 1.先明确本期唯一要解决的核心问题。
2. 2.定义最小可用流程和最常用的资料、角色或场景。
3. 3.列出本期不覆盖的扩展能力，例如编辑、下载、分类或外链协同。
4. 4.说明暂不做的阶段原因，而不是把它们判成没有价值。
5. 5.把扩展项保留为后续版本条件，避免在交付中不断顺手加入。

03_知识库/问题/什么是需求边界，为什么边界不清需求就会失控.md

一句话提醒

对会持续变化的对象，产品化不是一次交满，而是先交可用、可扩、可迭代的底座。

为什么今天看它

• 许多服务、系统和知识资产在交付后仍会随用户与场景变化。若第一次就封死结构，后续服务只能靠高成本重做，无法形成长期复利。

留一个问题

你正在交付的一项成果，是一次性问题还是会持续变化的对象？当前版本有没有为下一轮使用、反馈和扩展留出接口？

参考思路

1. 1.先判断对象是否会随时间、角色或场景持续变化。
2. 2.把第一次交付定位为可运行底座，而不是一次做满的终点。
3. 3.降低不可逆设计，保留模块化、可替换和可扩展空间。
4. 4.按生命周期拆出后续可能出现的变化和服务节点。
5. 5.用案例解释为何当时这样设计，以及它如何支持后续升级。

03_知识库/综合/把一次性交付改成长期关系：家装行业的产品化运营思路.md

一句话提醒

需求验证先确认场景、频次、影响和投入价值；需求成立不等于它现在必须排第一。

为什么今天看它

• 团队一旦直接讨论功能做法，就容易跳过需求强度判断。把验证问题问完整，才能分清真需求、伪需求和虽成立但暂不优先的事项。

留一个问题

你正在讨论的一项需求，目标用户、真实场景、使用频次、当前替代方式和不做影响是否都有证据？

参考思路

1. 1.确认目标用户与具体业务场景。
2. 2.观察问题是否稳定、高频地发生。
3. 3.了解当前替代方案及其时间、出错或协作成本。
4. 4.判断不做的影响和做成后的实际价值。
5. 5.先得出需求是否成立及其强度，再单独进入优先级排序。

03_知识库/问题/如何验证一个需求是否真的成立.md

一句话提醒

Prompt 讲清当前任务，全局配置写清长期协作的偏好、红线、纪律和不能重犯的错误。

为什么今天看它

• 高频且稳定的协作要求如果只存在于对话里，容易随上下文丢失。把它们沉淀为全局或项目规则，才能减少越界和重复踩坑。

留一个问题

你最近反复向 AI 交代的一条要求，是这次任务特有，还是应该升级成长期生效的全局或项目规则？

参考思路

1. 1.把当前任务的目标、背景、格式和限制放进单次 Prompt。
2. 2.把身份、沟通偏好、思维原则和协作方式写进长期配置。
3. 3.先定义必须先问的红线，再补风格与输出偏好。
4. 4.为项目补充改动纪律、验证方式和交付自检。
5. 5.把已发生且不该重复的错误沉淀为明确约束。

03_知识库/综合/AI 全局配置原则.md

一句话提醒

需求边界明确这次做到哪里、暂时不做什么，目的是保护当前阶段聚焦核心问题。

为什么今天看它

• “顺手加一下”的扩展最容易把一个核心问题膨胀成大系统。把本期不做的内容写清，才能让价值判断、交付范围和后续版本保持一致。

留一个问题

你正在推进的一项需求，能否清楚写出本期做到哪里、暂不做什么，以及哪些扩展不是没价值而是当前阶段不必要？

参考思路

1. 1.先明确本期要解决的单一核心问题。
2. 2.定义最小可用流程和最常用的资料、角色或场景。
3. 3.列出本期不覆盖的扩展能力，例如编辑、下载、分类或外链协同。
4. 4.说明暂不做的阶段原因，而不是把它们判成没有价值。
5. 5.把扩展项保留为后续版本条件，避免在交付中不断顺手加入。