推文

@fireandstart · 2026-10-17 13:00

这组结果最有价值的信号，不是“Prompt 越短越好”，而是先把成功标准变成 Eval，再用结果反推哪些指令真的有用。402 行降到 15 行、通过率从 62% 到 92%，说明提示词堆叠可能把角色、业务知识、执行步骤和边界条件揉在一起，模型反而更难抓住当前任务的重点。短只是结果，能测、能定位、能迭代才是方法。 Tool、Skill、Subagent 的划分也很实用：明确动作交给 Tool，按需知识放进 Skill，只有需要独立上下文时才开 Subagent；大量数据先用 Python 等确定性工具处理，再把结果交给模型。这不是为了少用模型而少用，而是让每一层只承担适合自己的责任。这样出错时也更容易判断，是工具执行、知识缺失，还是推理过程出了问题。 我尤其认同先采访需求、形成规格，再比较可预览方案，最后用 Schema、Fixture、Invariant 验收的流程。它把“我觉得做完了”变成别人也能检查的结果。自动化和长期记忆可以继续减少重复劳动，但前提仍是触发条件、保存内容和验收标准足够清楚。与其不断给 Agent 补一条新指令，不如先问：成功到底怎么衡量？这条规则应该属于哪一层？

曝光 24 · 评论 1 · 点赞 0 · 书签 0 · 曝光/时 23.944281802571584