先建知识网络，再持续扩内容

哪些信息应该常驻上下文，哪些只该按需注入？

哪些失败其实是信息过载或上下文冗余造成的？

你能把一个真实工作流拆成常驻上下文、临时任务状态和外部证据三层。

你能解释为什么 prompt 更长，常常意味着架构更差。

把 token 只理解成成本问题。

把所有规则、样例和上下文都塞进一个永久大块里。

什么答案应该直接来自模型，什么必须建立在检索证据或工具结果上？

什么时候任务太模糊，需要先澄清、拆解，而不是直接出答案？

你能把一次失败判断成能力问题、上下文问题、数据问题或工具问题，而不是统称 prompt 不行。

你能为模型不该直接回答的任务设计 fallback 行为。

因为回答流畅，就误以为模型真的知道。

默认模型能稳定回忆、稳定推理、稳定执行超出支持边界的任务。

这个任务最合适的输出格式是什么，系统如何自动验证它？

哪些要求应该写成自然语言，哪些应该变成硬 schema 约束？

你能把一个自由回答任务改成有明确 schema 的输出契约。

你能解释为什么解析失败要 loud fail，而不是静默接受坏结果。

让下游逻辑依赖自然语言句式而不是结构化字段。

把政策、风格和输出 schema 混成一个模糊指令块。

哪些信息应该在任务之间保持稳定，哪些必须每次刷新？

证据在哪里进入、过期、被审计？

你能把一个巨型 prompt 重写成不同层，并给每层定义更新规则。

你能判断一次错误是证据缺失、状态陈旧还是协议冲突造成的。

把所有规则、样例、证据都放进一个 system prompt。

不设计淘汰规则，导致历史上下文越堆越乱。

哪些信息应该按需检索，而不是永久留在上下文里？

检索之后，如何保留引用、来源和新鲜度信息？

你能为一个真实工作流画出查询、筛选、注入和引用的链路。

你能解释什么时候检索提高可靠性，什么时候只是把噪声塞进模型。

把太多文档直接塞进 prompt，却没有排序和过滤。

自称 grounded，但实际上拿不出证据来源。

哪些动作必须先有证据或确认，模型才有资格执行？

当链路依赖工具、provider 和 gateway 时，排错顺序应该是什么？

你能跑通一个工具工作流，并解释每个依赖节点在做什么。

你能把高频操作沉淀成 SOP 或 skill，而不是只会临场点点点。

主链路没通，就先加更多工具和插件。

只看 UI，不探测 gateway、pairing 和 tool readiness。

第一批最值得变成 eval 样本的真实失败是什么？

每个指标服务的是上线、回滚，还是优化优先级？

你能从自己的真实失败里做出一个最小 eval 集。

你能解释 eval 结果如何改变产品决策，而不是只做更漂亮的仪表盘。

用和真实业务脱节的 benchmark 代替 live failures。

把一次成功 demo 当成系统真的变好了。

要重放一次坏 case，系统必须记录哪些信息？

哪种 failure label 能帮助团队决定先修哪一层？

你能产出一条完整 run trace，包含 prompt、证据、工具链、输出和错误标签。

你能给出一条从系统状态开始，而不是从猜 prompt 开始的调试顺序。

只记录最终答案，不记录证据链和工具链。

还没重放失败，就先改 prompt。

这个 workflow 的质量到底由哪些维度决定：factuality、instruction following、citation、escalation judgment 还是别的？

怎样写 grader 规则，才能让第二个操作者或自动 grader 得出相近结论？

你能为一条真实 workflow 写出带维度、评分锚点和阈值的 rubric。

你能解释系统改好了什么：不只总分上升，而是哪一维度上升、为什么上升。

把整个系统压成一个模糊的 pass/fail。

只看平均分，不保留每条 criterion 的失败痕迹。

哪些指令绝不能被用户内容或检索文本覆盖？

哪些动作必须在执行前要求确认？

你能识别自己工作流中的一个 prompt injection 或 unsafe action 路径，并给出缓解步骤。

你能解释政策文字和真正可执行 guardrail 的区别。

把 safety 提示语当成 enforcement。

让用户输入或检索文档获得比系统规则更高的权限。

优先优化哪一层：模型选择、检索大小、输出长度还是编排逻辑？

用户真正感知延迟的位置在哪里，那里允许的 tradeoff 是什么？

你能找出一个工作流里最重要的两个延迟或成本杠杆，并设计实验。

你能解释压缩、路由、缓存或减少输出如何改变系统 tradeoff。

还没测清 retrieval 浪费和输出膨胀，就先盯模型单价。

为了快和省，直接牺牲证据质量和用户信任。

哪些文档允许直接支持用户回答，如何证明它们还有效？

文档进入检索前，必须具备哪些 metadata、负责人和 refresh policy？

你能为一类真实知识源定义 freshness class、过期阈值和 owner。

你能解释一次坏答案到底是没检索到、检索到了旧证据，还是压根没有治理规则。

以为文档索引一次就可以永远可靠。

把草稿、旧版本和正式版本混在一起，却没有优先级和 metadata 规则。

什么情况应该触发 hard stop：证据不足、权限不足、风险过高还是政策敏感？

人工 reviewer 最少需要什么 handoff packet，才能不是盲接和重复劳动？

你能为一条真实 workflow 定义 hard stop、review queue owner、SLA 和 handoff packet。

你能解释为什么升级给人是质量路径，不是产品丢脸。

只写“必要时转人工”，却没有触发规则和 owner。

升级时没有证据包，导致 reviewer 只能从头重建上下文。

游客、已登录用户、已订阅用户在产品里的状态到底应该怎么变化？

站内权限状态的真相源到底是什么事件？

你能演示游客、登录用户、订阅用户看到的是不同产品状态。

你能解释为什么账号状态、billing 状态和 UI 状态绝不能漂移。

把 success redirect 当成订阅真相源。

让 auth、billing 和页面状态各自独立演化。

用户学完之后，除了一个完成勾，还真正留下了什么资产？

什么证据能证明这不是拼凑 demo，而是完整产品？

你能演示从学习、到账户、到高级课解锁、到知识卡沉淀的完整链路。

你能解释自己的架构选择，以及最难收口的链路是什么。

只有很多功能页，没有一个完整产品故事。

只发布内容，不设计实践、验收和知识沉淀。