一句话提醒

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

为什么今天看它

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

留一个问题

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

参考思路

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