高子健
GAOZJAA

先判断用户真正痛点，再决定需要模型、数据、Prompt 还是工具动作。

• 01 /先把用户说出口的问题翻译成可观察的体验阻力：是不会用、效果不稳定、信息缺失，还是流程成本太高。
• 02 /不急着把问题归因给模型能力，先区分产品表达、数据覆盖、Prompt 结构、工具链路和评测口径各自的责任。
• 03 /把问题收束成一个可以被验证的判断句，让后续动作围绕同一目标推进。

将审美和体验判断拆成团队可以协作、模型可以学习、结果可以验证的语言。

• 01 /把“好看、像、顺、可用”拆成更具体的观察项，例如构图重心、文字层级、事实完整度和响应路径。
• 02 /标准不是为了写文档，而是让不同角色在同一张图、同一条 case 或同一轮版本里做出相近判断。
• 03 /当标准可以被复述、被标注、被评测和被模型学习，主观判断才真正进入协作系统。

优先建立小闭环验证价值，再决定是否投入更完整的工程和训练资源。

• 01 /先用最小样本、局部流程或可控对照证明方向是否值得继续，而不是一开始就投入完整工程化。
• 02 /验证重点不是只看正例是否变好，也要看 bad case 是否真的减少、成本是否变低、收益是否能稳定复现。
• 03 /如果小闭环已经暴露投入产出不成立，就及时止损，把结论沉淀为下一轮判断依据。

把一次性经验沉淀为评测、链路、工具或标准，让后续项目继续获得收益。

• 01 /每次项目结束后，都回收真正可迁移的部分：判断标准、评测集、Prompt 结构、工具流程或协作模板。
• 02 /复用不是复制结论，而是保留问题拆解方式和验证路径，让后续项目可以更快进入有效判断。
• 03 /能复用的结果会降低团队下一次试错成本，也能把个人经验转成组织可以继续使用的资产。