先别急着换工具,把“效果不好”拆成可检查的失败类型:是验收标准没定、上下文没给够、指令有歧义,还是任务本身超出模型稳定能力。多数情况属于前几类,能修;只有最后一类才接近“AI 暂时做不好”。
AI根据立正公开的文章和视频整理,不是他本人回复。重要的判断,请回到出处核对。
先定验收标准,再判断是不是AI不行
材料里的观点“效果不好”往往是因为一开始没写清楚什么算好。立正把这一步叫 evaluation design:每个任务都要有明确、可执行的验收标准,比如是否满足某个条件、是否避免了某类错误、是否覆盖关键边界情况、格式风格是否符合要求,而不是“看起来还行”1。标准定下来后,AI 甚至可以在输出前先自检,相当于加了一道质量闸门1。所以当你觉得效果不好时,先问自己:我能用一句话说清这次哪里不合格吗?如果说不清,问题多半在标准,不在模型。
AI失效分几类,不能都用换工具解决
立正强调 AI 失效不是一种问题,而是几类本质不同的问题,不能用一套万能动作去解决1。他列出的诊断方向包括:上下文缺失导致幻觉,要补信息;上下文窗口饱和导致信息丢失,要压缩或拆分;指令歧义导致方向偏差,要改写目标;模型能力边界导致任务超出当前模型稳定能力,才考虑换模型、换工具或降低任务复杂度1。你直接上手实现、效果不好时,先判断落在哪一类:如果是前三类,改的是你的输入和流程;只有反复确认前三类都排除了,才更可能是这件事当前 AI 做不稳。
让中间过程可见,才诊断得动
AI推演黑盒输出几乎没法调试。立正提到可观测性设计:让中间过程可见,包括工具调用轨迹、阶段性产物、自检结果、失败原因、修正动作,不是只看最终答案,而是看答案是怎么长出来的1。一旦过程可观测,问题能在早期暴露,不用等最终输出翻车才发现1。对你做工具来说,一个可试的做法是:让 AI 在关键步骤先输出中间产物(比如先给结构、再给内容),你检查这一步对不对,而不是等成品出来再整体判断好坏。这样你能分清是某一步没做好,还是整件事它做不了。
材料给的是诊断框架和分类,没有针对你具体那个工具的判断;哪一类是主因,要你拿自己的任务去核对。
出处
- 1AI User 与 AI Builder 的 5 个差距,和背后具体技术原因 | 科技大厂打工人版
最直接回答“怎么判断是AI不行还是用法问题”,给出验收标准、失效分类和可观测性三个可操作方向。
- 2AI已经用得很好,为什么还是怕被淘汰?
说明效果不好时应针对具体差距行动,而不是陷入整体否定,帮助你把问题落到可改的地方。
你也有想问的?
卡住的时候,问问立正:回答附有出处,可以点回原文核对。
问类似的问题也可以接着问:
别人还问了
- AI 的能力边界
AI 的边界不在它能不能生成,而在你能否判断什么重要、判断它错在哪、并替它把结果收口。
- Codex的长效文件是怎么使用的?是不是把它放到你要做的所有的项目里面然后每次要做一个事情就跟他讲先读一下再去执行。
不是靠每次口头提醒,而是让文件成为任务交接的介质:脚本把完整任务写进文件,AI 读文件、把结果写回文件,下游只认产物文件,不认会话里说过什么。
- 用多个agent协同合作来解决一个问题相比用单个agent有什么优势
多agent的优势只在任务能拆成可独立定义、可独立验收的子任务时成立;否则并行只会复制上下文、增加综合成本,产出更平庸。
- 要不要辞掉现在的薪水更高岗位?从而有更多时间时间?
资料不支持直接回答“该不该辞”,但立正反复讲的是:先分清你追的是自己的目的,还是别人给的标准;钱不够时它很重要,过了某个点继续加码可能买来的是更复杂的绑定。
- 你觉得ai转型 ceo可以交给cto做吗
资料里没有直接回答“AI转型能不能交给CTO”,但立正反复讲的判断是:转型的关键不在技术执行,而在谁对结果负责、谁设计系统、谁直接面对客户。
- 人活着的意义
立正认为人生没有唯一确定的意义,所以才有意义;他把体验本身当作最实在的东西,把金钱、分数这类外在标准看作工具而非目的。