最近看到一种观点，讲得很直白：
很多下游 AI 应用公司看起来是在用 LLM 提效，实际上却很难量化 AI 带来的真实收益。功能是上线了，调用量也涨了，但客户到底省了多少钱、赚了多少钱、愿不愿意为 AI 功能长期付费，并不清楚。与此同时，模型 API、云资源、推理成本和交付成本却是真金白银先花出去的。
最后的结果可能是：应用公司负责教育市场、打磨场景、承担交付和客服成本，利润却越来越多流向了上游模型厂商和云厂商。
这个判断听起来有点悲观，但我觉得不能简单把它归为“唱衰 AI”。
它指出的是 LLM 产业里一个很现实的商业问题：
模型能力已经可用，但应用层的价值闭环还没有完全跑通。
讨论 AI 应用有没有价值，很容易陷入两个极端。
一种极端是只看 demo。只要模型能写代码、能总结文档、能处理客服、能做 Agent，就默认它一定会带来巨大商业价值。
另一种极端是只看成本。只要推理要花钱、模型 API 要付费、云资源要扩容，就认为下游应用公司注定没有利润。
我觉得这两个判断都太快了。
真正应该先看的不是“AI 有没有用”，而是钱在产业链里怎么流。
我在整理一份 AI LLM 全球产业报告时看到一组很能说明问题的数据：
这些数字放在一起，问题就浮出来了：
上游的钱已经开始变得具体，下游的收益还经常停留在“感觉有用”。
算力厂商的收入是具体的，云厂商的资本开支是具体的，模型厂商的 ARR 是具体的。可是到了应用企业这里，经常变成“员工效率提升”“客户体验改善”“知识管理更智能”。
这些当然也可能是真的。但如果没有对应到成本下降、收入增长、留存提升、处理时长缩短、错误率下降这类指标，就很难判断它到底是不是商业收益。
传统 SaaS 有一个很重要的优点：边际成本相对低。
软件开发出来以后，多服务一个用户当然也有成本，比如服务器、带宽、客服、销售、运维，但核心功能的每次使用通常不会持续消耗一笔明显的外部采购成本。
AI 原生应用不一样。
只要每一次用户操作都要调用模型，就意味着每一次输出背后都有推理成本。用户越活跃，模型调用越多，成本也会跟着涨。
这会直接改变 AI 应用公司的毛利结构。
在传统 SaaS 里，用户活跃通常是好事。活跃说明产品有粘性，续费概率更高，单位经济模型更容易改善。
但在 AI 应用里，活跃用户往往意味着调用量上升。如果产品没有设计好用量边界、分层定价、模型路由和缓存机制，活跃本身就可能变成成本压力。
很多文章提到的“inference trap”，说的就是这个问题。VentureBeat 在 2025 年讨论过类似现象，把推理成本称为新的“cloud tax”。TechCrunch 在分析 AI coding startups 时也提到，AI 编程工具虽然增长很快，但高成本和薄毛利会持续压迫这类公司的商业模式。
AI 应用公司不是不能赚钱，而是没法像传统 SaaS 那样默认享受接近零边际成本的扩张逻辑。
每次调用都在重新做一遍成本测试。
我最认同那个观点的地方，不是“利润都会被模型厂商拿走”，而是“很多企业根本不知道 AI 带来了多少收益”。
这比成本高更危险。
成本高，至少还能优化。可以换模型，可以做 prompt 压缩，可以用小模型，可以做缓存，可以把一部分任务放到端侧或私有化部署。
但 ROI 算不清楚，就很难决定该优化什么。
比如一个客服 AI 系统，到底该看什么？
如果这些指标没有建立起来，只看“AI 回复了多少条消息”，就很容易变成热闹但没用。
代码助手也是一样。
不能只看它补全了多少代码、生成了多少行文本，而要看更靠近业务结果的指标：开发周期有没有缩短，缺陷率有没有变化，review 成本有没有下降，复杂任务是不是仍然需要人工反复返工。
MIT NANDA 那份被广泛讨论的 2025 年企业 GenAI 报告之所以引起这么大反应，也和这个有关。媒体转述的核心结论是，大量企业 GenAI pilot 没有带来可衡量的 P&L 影响。这个数字本身可以讨论，样本和口径也值得谨慎看待，但它戳中的问题是真实的：
很多 AI 项目停在 pilot、demo、内部试用和局部提效上，没有真正嵌进业务流程，也没有进入财务指标。
当收益还没进入财务指标时，成本已经进入账单了。
把“应用公司替模型厂商打工”这句话拆开看，里面压着几类成本。
最直接的是推理成本。
模型 API、云 GPU、向量数据库、RAG 检索、日志和监控，都会随着使用量上升而变成持续成本。
更重的是交付成本。
很多企业客户不是买一个聊天框就能解决问题。它们需要接入内部系统，整理知识库，配置权限，改造流程，培训员工，还要处理合规、安全和审计问题。
市场教育也要应用公司自己承担。
客户可能觉得 AI 很新鲜，但未必知道自己应该怎么买、怎么买才算值、该用什么指标验收。应用公司要花很大力气把一个技术能力翻译成业务价值。
还有一笔容易被忽略的失败成本。
一个 AI 项目如果没跑通，下游应用公司通常已经投入了销售、实施、模型调用、客户成功和支持成本。上游模型厂商则至少已经拿到了 API 或云资源收入。
产业报告里说的结构，对应的就是这个现实：
价值捕获前置，价值兑现滞后，风险承担下沉。
这句话比“模型厂商白白牟利”更准确。
模型厂商并不是没有成本。训练、推理、安全、研发、数据中心租赁和人才投入都很贵。云厂商也要承担 Capex、折旧、电力和算力利用率压力。Microsoft FY2025 物业和设备新增投入达到 645.51 亿美元，报告里也提到 Microsoft Cloud FY2025 毛利率降至 69%，AI 基础设施扩张是影响因素之一。
所以上游不是躺着赚钱。
但它们的位置更好。
只要下游要试错、要部署、要扩张，调用和云账单就会发生。至于最终客户有没有得到 ROI，那是下游更晚才会面对的问题。
不过，不能因此得出“应用层没机会”的结论。
应用层当然有机会，只是机会不在“套一个模型壳”。
真正有价值的 AI 应用，通常有几个共同点。
它要进入高频流程。
低频炫技功能很难支撑利润。一个月用一次的 AI 功能，即使效果不错，也很难成为客户持续付费的理由。
它还要能绑定业务结果。
客服看降本和满意度，销售看转化率和客单价，研发看交付周期和缺陷率，法务看审查时间和风险遗漏率。指标越具体，AI 的价值越容易被确认。
更关键的是，它要沉淀客户数据和流程权限。
如果一个应用只是把用户输入转给通用模型，再把回答包装一下，它的壁垒很薄。一旦模型厂商自己下场，或者竞品接入更便宜的模型，它就很难守住定价权。
但如果它掌握客户的业务数据、审批流、工具权限、行业规则和执行闭环，它就不再只是模型入口，而是业务系统的一部分。
最后，模型成本必须被管理起来。
这件事会越来越像数据库、缓存、CDN 和云成本优化。不同任务用不同模型，简单任务用小模型，复杂任务才调用强模型；能缓存就缓存，能批处理就批处理；能本地部署就评估本地部署，不能让所有请求无脑打到最贵的模型上。
AI 应用公司的核心能力，不只是“会调用模型”，还包括“知道什么时候不该调用最贵的模型”。
这个话题也能接回我前面写过的 Agent 和 Workflow。
很多 AI 应用失败，不是因为模型不够强，而是因为产品把太多不确定性直接扔给模型。
用户给一个模糊任务，Agent 自己规划、自己调用工具、自己循环执行。演示时很好看，但一到生产环境，就会遇到权限、日志、验收、异常恢复和成本控制问题。
如果一个流程本来可以拆成稳定步骤，用 Workflow 固定下来，成本和结果就都更容易测量。
比如客服场景，可以先分类，再检索知识库，再生成回复，再做合规检查，再决定是否转人工。每一步都可以统计耗时、成功率、调用成本和人工接管率。
如果直接让一个 Agent 从头到尾自由发挥，它也许能完成任务，但你很难知道成本花在哪一步，错误出在哪一步，优化应该从哪里开始。
商业上也是一样。
可控的 Workflow 更容易形成可控的单位经济模型。
不可控的 Agent 如果没有边界，就会把工程不确定性变成财务不确定性。
如果要判断一家 AI 应用公司是不是在替模型厂商打工，我不会先看它用了哪个模型，也不会先看 demo 多惊艳。
我会先看四个指标，但重点不是把表格填满，而是看商业压力到底落在哪里。
先看推理/API 成本占收入比例。
如果客户每多用一次，公司毛利就被明显侵蚀，那它必须有很强的定价权或成本优化能力。
再看 AI 功能的真实活跃使用率。
不是注册用户，不是试用人数，也不是生成次数，而是有多少用户在关键业务流程里稳定依赖它。
还要看客户可验证 ROI。
客户能不能说清楚用了这个产品以后节省了多少时间、降低了多少成本、增加了多少收入、减少了多少风险。
最后看净收入留存率。
如果客户用一段时间后愿意扩容、加购、续费，说明产品可能真的进入了流程。如果只靠新客户和融资维持增长，那就要小心。
这四个指标比“我们接入了最强模型”重要得多。
因为最强模型不是商业模式。
我对这个观点的结论是：
它不完全准确，但方向是对的。
不准确的地方在于，上游模型厂商和云厂商并不是无成本套利。它们也在承担巨额研发和基础设施成本。
方向对的地方在于，在当前阶段，LLM 产业确实存在价值捕获前置的问题。上游更早拿到确定收入，下游更晚证明客户价值。只要应用层不能把 AI 能力转化成可计量的业务结果，它就会在财务上变成上游增长的成本承担方。
AI 应用公司的问题，不是“要不要用 LLM”。
真正的问题是：
我花出去的每一次模型调用，最后有没有变成客户愿意长期付费的业务结果？
如果答案是清楚的，AI 就是产品能力。
如果答案说不清楚，AI 就只是账单上的一行成本。
ai_llm_industry_report_2026-06-03.html最近，很多人开始把 LLM 接到自己的工作流里。
一开始，大家最熟悉的形态还是 chatbot。国外有 ChatGPT、Gemini，国内有 DeepSeek、Qwen。用起来也简单：打开一个对话框，把问题发过去，等模型回答。
chatbot 是最早跑通大规模商业应用的大模型产品形态。它满足的需求很直接：让人可以用自然语言和机器交流。
早期的 chatbot 主要负责文字问答，能写一段文案、解释一个概念、翻译一段内容，就已经足够惊艳。后来模型能力越来越强，工具调用、代码执行、联网检索、文件处理、多模态输入陆续变成常见能力，chatbot 也开始发生变化。
它开始从问答工具，变成任务执行的入口。
比如读一份文档，整理会议纪要，修改代码，调用 API，操作网页，甚至连续执行一个比较长的任务。到了这个阶段，chatbot 和 Agent 的边界就开始变得模糊。
但这也带来了一个新的问题：
我的应用场景到底应该做成 Agent，还是做成 Workflow？
这个问题比“我要不要用 AI”更具体，也更直接影响系统上线后的稳定性和成本。
LLM 落地到具体业务里，通常有两条路线：Workflow 和 Agent。
Workflow 的特点是流程相对固定。LLM、工具、业务逻辑都按预先设计好的步骤运行。模型可以参与判断、生成、提取、总结，但它什么时候被调用、调用什么工具、结果交给谁，基本由程序控制。
Agent 则把更多控制权交给模型。任务怎么往下走，主要由 LLM 决定。它会根据当前环境和反馈判断下一步做什么、调用什么工具、是否需要调整计划，以及什么时候结束任务。
Workflow 是程序在调度模型，Agent 是模型在调度程序。
真正的差别就在这里。
很多团队一看到 Agent 的演示，很容易想：既然模型已经能规划、能调用工具、能自己循环执行，那是不是所有复杂任务都应该直接交给 Agent？
我的看法正好相反。
多数场景应该先从 Workflow 开始。只有当 Workflow 明显不够用时，再考虑 Agent。
原因很简单：Workflow 更容易控制，也更容易验收。
业务系统里最怕的不是能力不够强，而是行为不稳定。一个系统今天能跑通，明天因为输入略有变化就换一条流程，后天又因为工具返回异常开始自我发挥，这些不确定性很快就会抵消 AI 带来的效率提升。
所以，判断一个场景该不该上 Agent，第一步不是问“这个任务复杂不复杂”，而是问：
这个任务能不能被稳定拆成一组相对固定的步骤？
如果可以，通常应该先做 Workflow。
很多人会下意识觉得 Workflow 不如 Agent 高级。好像 Workflow 只是传统自动化，Agent 才代表未来。
这个理解不太准确。
在工程系统里，确定性本来就是重要收益。只要业务路径可以被清晰描述，Workflow 往往比 Agent 更可靠、更便宜，也更容易排查问题。
常见的 Workflow 设计方法，已经足够支撑不少实际需求。
第一类是提示链。
也就是把任务拆成一组固定步骤，每一步调用一次 LLM，并把上一轮输出作为下一轮输入。比如先从用户需求中提取关键信息，再生成结构化方案，然后检查遗漏，最后输出成固定格式。
这种方式适合任务边界清晰、步骤顺序稳定的场景。它的好处是每一步的任务都更窄，模型不需要一次性记住全部要求，也方便在中间环节做校验。
第二类是路由处理。
先用一个分类器或者 LLM 判断输入属于哪一类，再分发到对应的处理链路。比如客服系统里，退款问题走退款流程，物流问题走物流流程，技术问题走工单流程。
路由的价值在于把复杂问题拆散。每条路径只处理自己覆盖的输入类型，提示词、工具权限、校验规则都可以单独设计。
第三类是并行化。
有些任务天然可以拆成多个互不依赖的子任务。比如分析一份产品反馈时，可以同时抽取用户痛点、功能建议、情绪倾向和竞品线索。也可以让模型多次生成不同候选答案，再用投票或评分机制选出更可靠的结果。
并行化适合两类情况：要么是为了提升速度，要么是为了从不同角度交叉检查，降低单次模型输出的偶然性。
第四类是指挥官模式。
一个 LLM 先负责拆解任务，生成子任务列表；再把子任务分给不同模型或工具链处理；最后由汇总环节整合结果。
它已经比普通 Workflow 更灵活，但仍然保留了比较明确的结构。适合那些目标明确、但子任务数量和内容不太固定的场景。比如调研一个技术选型，可能需要查资料、对比方案、整理风险、形成建议，这些子任务不一定每次完全相同，但仍然可以放在受控流程里。
第五类是生成-评估循环。
一个模型负责生成结果，另一个模型或者规则系统负责评估、打分、指出问题，然后再回到生成环节做修改。
这种方式适合有明确评估标准的任务。比如代码补全能不能通过测试，摘要是否覆盖关键事实，文案是否满足品牌语气，配置文件是否符合 schema。
这些都不是“简单方案”。相反，它们是在工程系统中使用 LLM 的成熟做法。
如果一个需求能用这些 Workflow 稳定解决，就没有必要急着把它做成 Agent。
当然，Workflow 不是万能的。
当任务路径高度开放，步骤数量无法提前确定，或者执行过程中必须根据环境反馈不断调整策略时，Workflow 的维护成本会迅速上升。
典型表现是：流程图越画越大，分支越来越多，异常处理越来越零散，提示词越来越长，最后系统维护成本比任务本身还高。
这时候就该认真考虑 Agent。
Agent 的核心不是“会聊天”，而是循环：
observe -> think -> act -> observe
它读取当前状态，决定下一步动作，调用工具或执行操作，再根据新反馈继续调整。这个循环让 Agent 能处理一些难以硬编码的开放性问题。
比如一个复杂的决策流程，里面有大量例外情况，需要结合上下文做判断。你可以把所有规则都写进 Workflow，但规则越写越多，系统就越容易因为例外情况失效。Agent 反而可以结合上下文和工具反馈，在一定范围内做更灵活的处理。
再比如制度规则非常细、变化又频繁，人工维护成本很高。企业内部的审批、合规、报销、采购，经常会出现大量“满足 A，但不满足 B，C 又属于例外”的情况。完全硬编码当然可以，但每次制度变化都要改流程，长期看未必划算。
还有一种常见场景是高度依赖非结构化数据。
比如阅读合同，分析邮件往来，从一堆文档里找证据，和用户多轮沟通后完成一次业务处理。这里的输入不是规整字段，而是自然语言、图片、附件、上下文和隐含意图。Workflow 可以处理其中一部分，但很难提前穷举所有路径。
在这些场景里，Agent 的优势会更明显。
它可以先读懂当前材料，再按反馈逐步调整计划：调用不同工具，发现错误后重试，必要时改变路径。换句话说，它适合解决那些“你无法提前写死每一步”的问题。
选择 Agent，意味着把一部分控制权交给模型。
这不是坏事，但这一点必须先说清楚。
Agent 越自主，团队越需要提前想清楚几个工程问题：
如果这些问题没有设计清楚，Agent 很容易变成一个表面能跑、出了问题却很难定位和追责的自动化系统。
尤其是在生产系统里，答错只是风险的一部分；真正麻烦的是它执行了错误动作。
回答错一段话，用户可能还能识别。调用错一个接口、误删一份文件、把敏感信息发给不该访问的服务，后果就完全不同。
所以我并不建议把 Agent 当成 Workflow 的加强版，直接接进业务系统。它应该被看成一个能执行动作的系统组件，而且需要配套的权限、审计和防护机制。
Agent 可以灵活，但不能无限自由。
更稳妥的做法是设计分层防护。
第一层是输入相关性判断。先判断用户请求是否属于当前系统的职责范围，不相关的请求直接拒绝或转交其他流程。
第二层是安全分类。涉及隐私、违法、越权、危险操作的请求，应该走更严格的流程，不能让 Agent 自己决定是否执行。
第三层是工具分级。读取、搜索、写入、支付、删除这些工具的风险等级完全不同。高风险工具应该要求更严格的参数校验、权限控制，必要时还要人工确认。
第四层是输出验证。Agent 生成的结果不能默认可信。结构化输出要过 schema，代码要跑测试，财务金额要做规则校验，面向用户的内容要做事实检查和合规检查。
第五层是日志和回放。一次 Agent 执行过程中，模型看到了什么、做了什么判断、调用了什么工具、工具返回了什么、最后为什么结束任务，都应该尽量留下记录。没有日志，就没有可靠的排障和责任边界。
这些机制会让系统看起来没那么“智能”，但也会让它更接近一个能在生产环境里运行的工程产品。
能用 Workflow 稳定解决的问题，不要急着上 Agent；当分支、异常和上下文复杂度让 Workflow 难以维护时，再引入 Agent。
这是一笔工程成本的账。
Agent 的价值在于处理不确定性。如果任务本身没有那么多不确定性，强行引入 Agent 反而会增加调试、验收和风控成本。
Agent 和 Workflow 不是谁替代谁的问题。
它们更像同一条轴上的两个端点：一端是确定路径、程序调度、强约束；另一端是动态规划、模型主导、适应性更强。
真实系统里，两种方式往往会混用。
外层用 Workflow 约束主流程，里面某些开放环节交给 Agent。或者 Agent 负责探索和规划，关键动作仍然回到 Workflow 里执行。再或者，日常任务用 Workflow 批量处理，只有异常情况才交给 Agent。
最终，我们选择的不是某个听起来更新的概念，而是把多少自主权交给模型，以及如何在工程系统里管住这些自主权。
]]>Anthropic 和 OpenAI 的关系，一直有点微妙。
这两家公司当然是竞争对手，但又不只是竞争对手。Anthropic 的几位核心创始人本来就出自 OpenAI，后来因为对 AI 安全、商业化节奏和组织治理的理解不同，另起炉灶做了 Claude。于是，今天再看 OpenAI 和 Anthropic 的公开研究，经常会有一种很奇妙的感觉：他们明明都在讲安全、讲对齐、讲负责任的模型能力，但读起来总像是在隔空回应。
最近关于 AI 大模型可监控性的几篇文章，就很有这种“针锋相对”的感觉。
先是 OpenAI 发了一篇文章，讨论推理模型对思维链（CoT）的控制能力。它的问题很具体：如果我们把模型自己输出的推理过程用来做风险监控，那么模型会不会故意把这段推理过程“粉饰太平”？
OpenAI 的观点是：至少现在，模型还不太擅长稳定控制自己的思维链，所以 CoT 监控仍然是一个有价值的监控方法。
这本来已经是一个有趣的发现。结果不久后，Anthropic 果断回击：别急着相信模型说出来的东西，因为模型内部可能已经有一些“没说出口”的判断。
Anthropic 发了一篇 Natural Language Autoencoders，试图把 Claude 内部数字形态的激活（activations）翻译成自然语言。
两篇文章都没有直接点名对方，但放在一起看，很难不觉得它们在围绕同一个问题拉扯：
当 AI 系统越来越复杂，我们到底还能不能看见它为什么这么做？
OpenAI 讨论的是推理模型的 CoT，也就是模型在解决任务时生成的中间推理步骤。
过去很多人对 CoT 监控抱有期待。理由很直观：如果模型在行动前会把自己的推理过程写出来，那么我们就可以从这些推理轨迹中发现不安全意图、错误计划，或者偏离用户目标的行为。
这就像在模型行动前，多看了一眼它的草稿纸。
但这立刻带来另一个问题：
如果模型知道自己的 CoT 正在被监控，它会不会故意去修改 CoT，把它改得更安全、更干净、更不暴露真实风险？
OpenAI 把这个问题称为 CoT 可控性。它测试模型是否能遵守一些关于 CoT 的指令，比如避开某些关键词、改变推理格式，或者添加特定模式。结果显示，当前前沿推理模型的 CoT 可控性普遍较低。
这就是 OpenAI 文章标题里“难以掌控 CoT，但这反而是件好事”的含义。
如果模型还不能稳定操控自己的 CoT，那么 CoT 监测在现阶段就仍然值得去当作监管手段。
这是一种相对乐观的判断。问题是，Anthropic 很快把镜头往更深处推了一层。
Anthropic 的 Natural Language Autoencoders（NLA） 文章，看起来像是对这种乐观判断的一次补充，或者应该说是反驳。
它最吸引人的地方不是技术细节，而是提出了一个很容易传播的说法：
AI 模型可能没有在输出中明说某件事，但它的 activations 中已经包含了相关判断。
Anthropic 的方法大致是，把模型内部的 activations 转成自然语言解释，再尝试从这段解释重构原始 activations，即 NLA。如果解释能帮助重构 activations，就说明这段解释（至少）捕捉到了（一部分）内部状态。
这套机制的目标不是让模型继续解释自己的输出，而是绕过最终输出，直接观察中间表征。
更有冲击力的是 Anthropic 举的例子。在一些安全测试中，Claude 的推理过程并没有说“我正在被测试”。但 NLA 给出的解释显示，它的内部状态里可能已经出现了类似“这是一个测试场景”的判断。
这就抛出了一个很有戏剧性的问题：
AI 会不会隐瞒自己的想法？
如果用人类语言描述，这当然很像“心口不一”。模型表面上没有说，内部却已经“知道”。但这里也正是最需要小心的地方：这种表述虽然有传播力，却很容易把问题拟人化。
从工程角度看，更准确的说法也许是：
大模型的输出文本只是系统状态的一种外显结果，并不等于全部内部状态。模型内部可能存在一些没有被最终输出显化的中间表征，而这些表征仍然可能影响后续行为。
无论是“心口不一”还是“表达差异”，形成这个结论就已经足够重要了。
因为一旦 AI 系统进入代码执行、网页操作、长任务规划等场景，我们关心的就不只是它最后说了什么，而是它在行动前是否已经形成了某些风险信号。
OpenAI 关心的是：模型说出来的 CoT 是否还能被信任。
Anthropic 关心的是：模型没说出来的内部状态是否也应该被看见。
一个看外显推理，一个往里看。一个强调“输出仍有用”，一个提醒“输出不够”。
他们实际上在争论一个更底层的问题：
可靠监督的入口到底在哪里？
如果入口是模型自己生成的 CoT，那么重点就是保护 CoT 的真实性，避免把模型训练成只会输出漂亮、安全、被修饰过的推理文本。
如果入口是模型内部 activations，那么重点就是发展可解释性工具，把高维表征翻译成人类可以理解的证据。
这两条路线当然并不互斥。现实中更可能需要两者配合：CoT 监控负责观察外显推理， activations 解释负责补充那些没有说出口的内部状态。
但它们确实存在路线竞争。因为资源、注意力和安全叙事是有限的。到底应该优先投入 CoT 监控，还是优先投入 activations 解释？这些问题都会影响未来大模型的训练方式和产品形态。
如果只看 OpenAI 和 Anthropic，这个问题已经足够有趣。但再往外看，会发现这不是两家公司之间的小分歧，整个 AI 安全领域都在绕着这个问题打转。
Apollo Research 和 Frontier Model Forum 更接近 OpenAI 的方向，但措辞更谨慎。它们认为 CoT 监控虽然脆弱，但很重要。只要模型还需要用自然语言完成复杂推理，人类就有机会通过监控 CoT 发现不安全的意图。
但它们也强调，CoT 不是唯一答案。未来模型可能学会隐藏意图，开发者也可能为了让输出更美观、更符合产品预期，把 CoT 训练得越来越不像真实推理。因此，它们主张把 CoT 可监控性当作一项安全特性来保护。
METR 的视角更工程化。它关心的不只是 CoT 是否“诚实”，而是整个评测系统是否能抓住模型的真实能力和潜在行为。即使某些 CoT 未完全表达意图，它仍然可能包含有用信号；但这些信号能否用于高风险场景，还需要和其他监控与控制方法结合。
Google DeepMind 和 UK AISI 则把问题放进更大的安全框架。它们更关注前沿模型的能力阈值、危险能力评估、防御规避能力和国家安全风险。可监控性在这里不是单项技术，而是整个风险管理体系中的一环。
NIST 和 Future of Life Institute 的角度更偏治理。它们不会押注某一种具体技术，而是强调风险识别、可测量、管理、外部评估、信息披露和问责机制。换句话说，即使 CoT 监控和 activations 解释都在进步，企业仍然需要回答：谁来评估？如何复现？失败是否披露？风险超过阈值时是否停止部署？
到这里，问题已经从“能不能看见模型在想什么”，变成了“一个越来越复杂的 AI 系统，应该如何被持续观察、约束和审查”。
这时候再回头看 OpenAI 和 Anthropic 的分歧，就不会觉得它只是两家公司在争路线。它更像是一个更大问题的两个切面：
一边是语言监控路线，观察模型自己生成的 CoT。
一边是内部解释路线，观察模型的 activations、表征和机制。
再往外，还有系统治理路线，通过评测、审计、披露和监管来兜底。
到这里，我想回到“AI 会不会隐瞒自己的想法”这个问题本身，重新回答一下。
我始终认为，AI 大模型是作为“工具”的一种存在，不具备人格。
它没有人类意义上的自我意识、欲望、羞耻心或道德意图，也没有人类特有的连续内心世界。因此，当我们说模型“隐瞒想法”“伪装推理”“意识到自己被评测”时，需要非常谨慎。
这些说法有助于传播，但也容易误导。
更准确地说，大模型是在训练目标、上下文输入、推理机制和反馈信号共同作用下，生成某种输出和行为。它可能表现出类似隐瞒、规避、装乖的模式，但这不等于它像人一样“故意”隐瞒自己的想法。
这里的区别很重要。
如果我们把 AI 当成人，就很容易追问：它到底在想什么？它是不是有恶意？它是不是想骗我们？
但如果我们把 AI 当作复杂工具系统，就会变成工程问题：哪些内部状态与风险行为相关？哪些外显推理信号仍然可信？哪些日志、activations、工具调用、行为轨迹可以被记录和审查？哪些评测能暴露规避行为？哪些部署机制能在风险升高时及时切断？
我更相信后一种提问方式。
AI 不需要具备人格，才会产生难以直接观察的中间状态。
飞机没有人格，飞控系统仍然需要黑盒记录和传感器监控；自动驾驶系统没有人格，仍然需要感知解释、轨迹记录和安全冗余。
大模型也是一样。
我们不必假设它“有心隐瞒”，也应该承认它的内部状态和行为路径会越来越复杂。可监控性的目标不是证明 AI 有人格，而是把这些复杂状态转化为可测量、可解释、可审查的工程对象。
所以，我对 AI 大模型可监控性的判断偏乐观。
不是因为我相信模型会天然诚实，也不是因为我相信某一种监控技术已经成熟，而是因为我认为问题本身可以被工程化拆解。
CoT 监控可以观察外显推理， activations 解释可以补充内部表征，行为评测可以观察真实任务表现，对抗测试可以寻找规避路径。
工具调用日志可以记录行动链路，权限系统可以限制可执行动作，外部审查和治理框架可以把技术信号转化为责任机制。
这些方法没有任何一个能单独解决问题，但它们叠加起来，就能把“不可见的模型状态”逐步变成“可观测的系统行为”。真正可靠的可监控性，应该不会来自单一路线，而会来自多层叠加。
因此，可监控性不是一个抽象哲学问题，也不是一个人格判断问题。它更像是安全工程、可解释性、系统设计和治理机制交叉形成的一组能力。
更重要的是，只要我们不被“AI 是否真的在想”这个问题带偏，而是持续追问“哪些状态可以被测量，哪些行为可以被审查，哪些风险可以被提前发现”，那么 AI 大模型的可监控性就不是空中楼阁。
它应该，也一定会成为 AI 工程体系中的基础能力。
最近在开发一套 PPP 精密单点定位软件，在设计滤波器的时候关注到了 SRIF。 参考过去的经历，由于嵌入式 GNSS 资源严重受限，矩阵维度不会很大，主要关注滤波器的稳定性，一般会用平方根滤波 SRKF 或者 UDKF。 而新软件的维度要大的多，还要考虑未来的多源融合扩展，值得学习一下 SRIF。顺便整理一下 SRIF 与 SRKF 的差异。
GNSS 定位本质上是一个状态估计问题。位置、速度、接收机钟差、对流层延迟、载波相位模糊度，都可以放进状态向量；伪距、载波相位、多普勒这些观测，则不断给状态增加约束。滤波器要做的事情，就是在先验模型和观测信息之间做一个合理的折中。
如果只是做一个单站定位，状态维度通常不算大，用常规 Kalman Filter 或者它的平方根版本，大多数时候已经够用。比如嵌入式 GNSS 接收机里，算力和内存都比较紧张，滤波器设计的重点往往是稳定、直接、好调试。SRKF 或者 UDKF 在这类场景里就很常见。
但如果问题规模继续往上走，情况就会变得不太一样。比如 PPP 软件里引入更多频点、更多系统、更多状态参数，再进一步考虑多源融合、滑动窗口、甚至多站联合处理，状态维度和观测数量都会明显增加。这时候矩阵结构、数值稳定性和计算代价同样重要。
SRIF 值得关注，正是因为它同时踩中了这几个点。
平方根滤波的基本想法很朴素：不直接维护协方差矩阵或信息矩阵，而是维护它们的平方根因子。这样做的好处是数值上更稳，矩阵正定性更容易保持，也更适合用 QR 分解这类稳定的数值方法来更新系统。
SRIF 更进一步，它站在信息矩阵这一侧看问题。相比协方差矩阵，信息矩阵更容易保留 GNSS 观测中的稀疏结构。简单说，观测只会连接少数几个相关状态，而不是一下子把所有状态都混在一起。这个特点在小规模滤波里不一定显眼，但在大规模 GNSS 估计问题里会越来越重要。
所以这篇文章不打算把 SRIF 讲成一个纯数学概念，而是从 GNSS 软件实现的角度，重点整理几个工程上绕不开的问题：SRIF 和 SRKF 到底差在哪，分别适合什么场景，信息矩阵和协因数阵是什么关系，以及稀疏矩阵背后的图连通性该怎么理解。
先从更熟悉的 Kalman Filter 说起。
标准 Kalman Filter 维护两个核心量：一个是状态估计，另一个是状态误差协方差：
\[\hat{x},\quad P\]这里的 $P$ 描述的是状态估计误差的不确定性。对 GNSS 来说，它可以告诉我们位置、钟差、对流层、模糊度这些状态分别有多不确定，彼此之间又有什么相关性。
SRKF，也就是 Square Root Kalman Filter，并不直接维护 $P$，而是维护它的一个平方根因子。例如：
\[P = SS^T\]也可以采用其他分解形式，比如上三角因子或 UD 分解。具体选哪一种，和软件实现、矩阵库、数值习惯都有关系，但核心思想是一致的：不要直接在协方差矩阵上做更新，而是在它的因子上做更新。
这么做的好处很实际。普通 Kalman Filter 在有限精度计算下，协方差矩阵可能会慢慢失去对称性，甚至出现不再正定的问题。状态维度小的时候，这类问题不一定频繁暴露；但在长时间运行、弱观测、强相关状态较多的时候，就会比较烦。SRKF 通过平方根形式更新，数值稳定性更好，也更容易保持协方差的正定性。
从工程使用上看，SRKF 和传统 KF 的思路很接近，预测、更新、输出精度指标都比较直观。如果我们关心的是实时定位结果，以及每个状态的标准差、协方差、相关系数，那么协方差形式天然就很顺手。
所以在单站 RTK、实时 PPP、GNSS/INS 组合导航这些场景里，SRKF 是一个很自然的选择。状态规模不大，实时性要求强，还经常需要输出精度信息，这些都刚好是 SRKF 擅长的地方。
SRIF 的出发点不一样，它不是从协方差矩阵这一侧看问题，而是从信息矩阵这一侧看问题。
信息滤波器维护的是信息矩阵和信息向量：
\[\Lambda = P^{-1},\quad \eta = \Lambda \hat{x}\]其中 $\Lambda$ 是协方差矩阵的逆。协方差矩阵表达的是“不确定性有多大”，信息矩阵表达的则是“约束有多强”。这两个说法看起来只是正反两面，但落到矩阵结构上，差别会非常明显。
SRIF，也就是 Square Root Information Filter，维护的是信息矩阵的平方根因子：
\[\Lambda = R^T R\]这里的 $R$ 通常是一个三角因子。观测更新时，可以把先验信息和新观测方程堆叠起来，然后通过 QR 分解得到新的信息因子。最后需要状态解的时候，再通过三角回代求出 $\hat{x}$。
这个过程和加权最小二乘非常像。甚至可以说，SRIF 更像是把最小二乘的 QR 分解写成了递推滤波形式。也正因为如此，它和批处理平差、滑动窗口估计、因子图优化之间的关系会更近。
在 GNSS 里，这个视角很有用。很多观测并不会同时约束所有状态，而是只和少数状态有关。比如某一颗卫星在某一个历元的载波相位观测，通常只会连接接收机状态、卫星相关改正、对流层参数和对应的模糊度。变量很多，但单条观测涉及的变量并不多，这就是典型的稀疏结构。
SRIF 的优势就在这里：它不仅是“平方根形式更稳定”，还可以更自然地利用信息矩阵里的稀疏性。
SRKF 和 SRIF 名字都带 Square Root，容易让人觉得它们只是同一类方法的两个变体。但真正的差别不在“平方根”，而在“协方差形式”和“信息形式”。
SRKF 维护的是协方差的平方根。它关心的是状态误差怎么传播，也就是“我现在还不确定多少”。预测时，过程噪声会让不确定性变大；更新时，观测会让不确定性变小。这套逻辑和传统 Kalman Filter 完全一致，只是数值实现更稳。
SRIF 维护的是信息矩阵的平方根。它关心的是约束信息怎么累积，也就是“我已经被哪些观测约束住了”。新的观测进来，相当于给状态系统增加一组新的约束；旧状态被边缘化，相当于在信息矩阵里做一次变量消元。
工程上，两者的手感也不一样。
SRKF 更容易直接拿到协方差。定位软件里如果需要频繁输出状态标准差、位置协方差、DOP 相关指标，协方差形式会比较方便。SRIF 则更容易和稀疏矩阵、QR 分解、变量消元这些东西结合起来。它对大规模问题更友好，但如果你想拿完整协方差，反而需要额外计算。
可以粗略地说，SRKF 更像传统实时滤波的稳定版本，SRIF 更像递推版的加权最小二乘或者因子图求解器。这个类比不完全严格，但对理解它们在软件里的定位很有帮助。
如果只看理论，SRKF 和 SRIF 都能处理滤波问题。但到了工程实现里，适用场景还是有明显差异。
SRKF 更适合状态维度中小、实时性强、需要频繁输出协方差的场景。比如单站 PPP、RTK、GNSS/INS 组合导航，这些问题的状态规模通常可控，而且软件经常要给外部模块提供位置精度、速度精度、姿态精度等结果。此时协方差形式很直接，调试也比较方便。
SRIF 更适合状态维度较大、观测约束比较局部、希望利用稀疏矩阵的场景。比如多站网络解算、滑动窗口估计、后处理平滑，或者未来要把 GNSS 和更多传感器、更多先验约束放到一个统一估计框架里。变量一多，矩阵结构就很重要。如果还用稠密协方差去硬算，很容易把计算量和内存都推上去。
当然，这里不是说 SRKF 只能做小问题，SRIF 只能做大问题。真正的选择还要看状态设计、观测模型、边缘化策略、矩阵库能力，以及你到底需要输出哪些结果。
但作为一个经验判断，可以先这么记：小而实时，用 SRKF 很顺手；大而稀疏，用 SRIF 更舒服。
讨论 SRIF 时，很容易把信息矩阵、协方差矩阵、协因数阵混在一起。尤其 GNSS 和测量平差领域经常会说“协因数阵”，但它和信息矩阵不是一个东西。
先看协方差矩阵：
\[P\]它表示状态估计误差的不确定性。对角线元素是各个状态的方差，非对角线元素是状态误差之间的协方差。
再看协因数阵：
\[Q_x\]它常见于测量平差里，通常和单位权方差一起出现：
\[P_x = \sigma_0^2 Q_x\]也就是说，$Q_x$ 更多描述的是设计矩阵、权阵、观测几何带来的结构；乘上单位权方差 $\sigma_0^2$ 之后，才得到实际意义上的协方差矩阵 $P_x$。
信息矩阵则是另一侧：
\[\Lambda = P^{-1}\]它是协方差矩阵的逆，表示约束强度。如果协方差大，说明不确定性大，信息就少；如果协方差小，说明约束强，信息就多。
所以直观上，协方差矩阵和协因数阵更像是在描述“误差有多大、误差之间怎么相关”；信息矩阵更像是在描述“变量之间被哪些观测绑在一起、约束强度有多大”。
这点对理解 SRIF 很关键。SRIF 的稀疏性主要体现在信息矩阵这一侧，而不是协方差这一侧。很多情况下，信息矩阵可以很稀疏，但它的逆，也就是协方差矩阵，可能已经比较稠密了。
信息矩阵的稀疏性，可以用图来理解。
把每个状态变量看成图里的节点。如果两个变量同时出现在某个观测方程里，它们之间就存在一条边。反映到信息矩阵里，通常就是对应位置出现一个非零块。
GNSS 观测很适合这种图模型的理解方式。一个伪距或载波观测，可能会连接接收机位置、接收机钟差、卫星钟差改正、对流层参数、模糊度参数。但它不会连接系统里的所有状态。换句话说，每条观测只是在大图里加了一小块局部连接。
当观测很多、状态很多时，这些局部连接会组成一个很大的稀疏图。图的连通性可以告诉我们很多事情：哪些变量被共同约束，哪些变量其实属于独立子问题，哪些地方连接太弱，可能导致病态或者不可观。
这也是为什么信息矩阵比协方差矩阵更适合表达这类结构。信息矩阵里的非零块，基本对应变量之间的直接约束关系；协方差矩阵里的相关性则可能是间接传播出来的，往往更容易变稠密。
不过，稀疏不等于自动高效。SRIF 里做 QR 分解或变量消元时，可能会产生填充。图上看，就是消掉一个节点后，它的邻居之间可能被连成一团。消元顺序选得不好，本来很稀疏的问题也可能变得很重。
所以 SRIF 想跑得快，变量排序很关键。哪些状态先消，哪些状态后消，哪些状态保留在窗口里，本质上都是在管理这张图的结构。
最后回到一开始的问题：什么时候该认真考虑 SRIF？
如果只是单站实时定位，状态维度不大，软件也需要频繁输出协方差，那 SRKF 或者传统 KF 已经很好用。尤其在嵌入式 GNSS 里，简单、稳定、可控，本身就是很重要的工程优势。
但如果问题开始变成多系统、多频点、多历元、多状态，或者要处理大量模糊度参数、滑动窗口、后处理平滑、多站联合估计，那 SRIF 就值得认真考虑了。
它的优势不只是“平方根形式更稳定”，更重要的是它能把 GNSS 问题里的稀疏约束结构用起来。对大规模估计问题来说，这往往比单纯换一个滤波公式更重要。
这也是 SRIF 和现代因子图优化关系很近的原因。二者背后都在处理同一件事：把观测写成约束，把变量组织成图，然后用稳定的矩阵分解方法求解。
]]>不积跬步，无以至千里。
前面几篇谈的是如何认识 AI、如何准备上下文、如何引导思考，以及如何把 AI 用在写作里。到这一篇，事情继续往外走：AI 不只在文字方面擅长，它还能看图、听音频、读表格、写代码、生成图像，甚至帮你把一个想法做成可以点击的小工具。
这并不意味着提示词技巧失效了。恰恰相反，越接近真实作品，越要把目标、材料、约束和评价标准说清楚。多模态和应用生成不是“随便一句话变出万物”的魔法，仍然离不开前面学过的方法：先把问题说清楚，再把材料备好，再让 AI 一步步帮你研究、生成、验证和改进。
同时也要记住，媒介越复杂，成本和风险通常越高。文本生成最快，图像和语音更慢，视频往往更慢也更贵；语音克隆、人物视频和仿真内容还会带来身份冒用、版权和职业影响等伦理问题。能做的事情越多，越要先想清楚哪些能做、哪些不该做。
现代 AI 的一个重要变化，是能吃进去的材料更多，吐出来的结果也更多。过去我们主要给它一段文字，让它再返回一段文字；现在，你可以把截图、照片、录音、表格、PDF、代码文件夹交给它，也可以让它输出文字方案、图片、图表、代码、网页应用，甚至语音和视频素材。
这件事的意义不在炫技，而在于AI 能看到更多现场材料。很多事情用文字描述很费劲，直接给材料反而清楚。你想让 AI 分析一个网页设计哪里别扭，与其写十句话描述按钮位置，不如上传截图；你想让它整理一次头脑风暴，与其回忆白板上写过什么，不如拍照给它看；你想分析家庭开支，与其说“感觉这个月花多了”，不如上传账单表格。
因此，多模态真正改变的是协作方式。你不再只是在聊天框里“问问题”，还可以把现实里的材料带进来，让 AI 一起整理、理解和生成。提示词的重点也不再是“写一句漂亮口令”，而是把任务现场交代清楚：这份材料是什么，想解决什么问题，哪些信息可信，哪些地方需要复核，最后希望得到什么形式的结果。
需要注意的是，媒介变多并不等于判断可以放松。图片会看错，音频会转写错，表格会读错列名，代码会有漏洞。越是接近实际产物，越要记住一句话：AI 可以扩大你的处理能力，但不能替你承担最终责任。
图片是最容易上手的多模态输入。它适合交代场景、结构和证据：收据、白板、便签墙、课堂板书、产品截图、手写草图，都可以成为 AI 理解任务的材料。
比如一群朋友聚餐后，收据上有十几道菜、服务费和优惠券。你可以上传收据，再补充“张三没有喝酒，李四单独点了甜品，其余菜品均摊”，让 AI 帮你计算 AA。再比如开会后白板上写满了箭头、圈点和便利贴，你可以拍照，让 AI 先整理出讨论主题、已达成结论、待确认问题和负责人。课堂板书也是类似场景：拍下推导过程，让 AI 根据图片总结知识点，再标出哪些公式需要你自己核对。
图片输入的好处，是省掉很多说不清的描述。一个页面布局、一个手绘流程、一张设备面板，有时用自然语言讲半天也讲不清；上传图片后，再用一两句话说明任务，AI 往往能更快明白你要做什么。
但图片理解也有短板。OCR 可能把数字 8 识别成 3，把小数点漏掉，把手写字看成另一个词；图像模型也可能对细节过度自信。医疗影像、法律文件、财务票据、精密设备型号这类场景，尤其不能只靠它下判断。比较稳妥的做法是：让 AI 先整理和提取，再由人复核关键数字、名称和结论。如果结果会影响付款、诊断、合同、报销或安全操作，复核就是必选项。
让 AI 生成图像时，很多人一开始只写“画一只猫”、“做一张海报”，结果常常很普通。原因和写作一样：要求太空洞，AI 只能按最常见的视觉套路往里填。想写出更好的图像提示词，先要学会一点简单的视觉语言。
一个可用的图像 Prompt，通常至少包含四类信息：主体、场景、细节和风格。主体是画面中最重要的对象；场景说明它在哪里、什么时间、什么环境；细节决定动作、物品、构图和光线；风格则限定摄影、插画、水彩、电影感、国风、产品渲染等方向。
比如下面这句就比“画一只猫”清楚得多：
一只猫在夜晚秘密经营咖啡馆，木质桌椅，暖色灯光，窗外有细雨，电影感构图，柔和阴影。
这里的重点不在堆砌形容词，而在先把画面框住。你也可以继续修改：“保持猫和咖啡馆主题不变，把构图改成从窗外往里看”“减少杂物，让桌面更干净”“把色调改得更像儿童绘本”。图像生成很少一次到位，更稳妥的做法，是先确定方向，再针对具体问题修改。
如果已有参考图，编辑图像通常比从零开始做图更容易把控。比如你要做一张活动海报，可以先上传现有版式，让 AI 调整色调、替换背景、增加留白，别让它凭空猜你的品牌气质。只是要记住，图像、视频和语音生成成本通常高于文本，随机性也更强，不适合无限试错。开始前先确定用途、尺寸、风格和不可改变的元素，会比反复“再来一张”更有效。
图像生成本身也带有随机性。同一个提示词，多次生成可能得到不同构图；手指、文字、连续多帧中的角色一致性，也仍然是容易出错的地方。更稳妥的办法，是先多生成几张，从里面挑一个方向，再围绕明确问题做少量修改，不要指望第一张就完全满意。
AI 做数据分析时，比较可靠的方式是让它读取数据、理解问题、编写代码、运行计算、生成图表，再解释结果，少让它口头猜。最关键的是中间那一步：用代码把数据算出来，少让模型凭印象编结论。
生活里有很多适合这种方式的任务。你可以上传跑步记录，让 AI 统计每月的距离、配速变化和休息间隔；上传家庭开支表，让它按餐饮、交通、住房、娱乐重新分类，并找出异常增长项；上传店铺销售数据，让它画出月度趋势，比较销量变化最大的产品；上传调查问卷，让它汇总选择题、归纳开放回答，再指出高频反馈。
提示时要把“算什么”和“怎么解释”分开。例如：
请读取这份销售数据，找出销量变化最大的产品，画出月度趋势图，并说明可能原因。请区分计算结果和你的推测。
这句提示里最重要的是最后一句。数据分析里，计算结果、图表观察和原因推测不是一回事。销量下降 18% 是计算结果；下降集中在 7 月和 8 月是图表观察；可能与促销结束、缺货或竞争对手活动有关，则是推测。请 AI 明确区分事实和解释，能减少很多看似严谨的误导。
当然，让 AI 使用代码做计算也并不总是可靠。表头可能理解错，缺失值可能处理不当，单位可能混用，日期格式可能被误读。涉及财务、经营、医学实验、合规报表这类重要场景，最好要求 AI 展示关键计算逻辑，并抽查几行原始数据。AI 可以替你提高分析效率，但重大决策仍要有人复核。
当 AI 能写代码之后，Prompt 就不只用来生成文本，也可以用来生成工具。简单网页、小游戏、账单分摊器、单词卡、配色工具、番茄钟、预算仪表盘，都可以从一段清楚的需求开始。
构建小应用时，最基础的提示至少要讲清三件事：目标、输入和输出。目标说明这个应用解决什么问题；输入说明用户如何操作；输出说明应用返回什么结果。比如：
请做一个番茄钟网页应用。
目标：帮助用户进行 25 分钟专注和 5 分钟休息。
输入：用户可以开始、暂停、重置，并切换专注/休息时长。
输出：显示倒计时、当前状态和完成提示。
如果想让结果更可用，还可以补充约束：在手机上也能使用，按钮要足够大，状态切换要明确，刷新页面后是否保留设置，完成时是否播放提示音。你会发现，写应用 Prompt 和做产品需求很像。区别只是，AI 能很快把模糊想法变成第一版原型，而你要负责判断它是否真的符合使用场景。
这里也要控制预期。AI 很适合从零做一个小工具原型，或者在现有项目里实现一个清楚的功能；但多人在线游戏、实时协作系统、支付流程、复杂权限、长期维护的数据库产品，通常不适合一句话一步到位。更好的做法是先把最小功能跑通，再一点点加东西：先让账单计算器能正确分摊，再加保存记录；先让单词卡能翻面，再加复习计划；先让仪表盘能读本地数据，再考虑登录和云端同步。
应用生成的关键，不该是让 AI 一次写出“完整产品”。更实际的做法，是让它帮你尽快验证一个想法值不值得继续做。哪怕只是一个烟花小动画、配色工具或单词卡，只要能在浏览器里打开、发给朋友试用，它就已经不只是聊天记录，而是一个可以被别人使用的小作品。
把多模态、数据分析和应用生成放在一起看，AI 已经不只是在“回答一句话”，也可以帮你“做出一个东西”。但这件事通常不是一步完成的，而是一步一步往前推：先头脑风暴，再查资料，再构建，再分享，再根据反馈修改。
比如职业选择。你可以先让 AI 帮你头脑风暴可能的职业路径，再搜索各行业的岗位要求、薪资区间和发展趋势；接着整理成对比表，最后做一个自测小工具，让自己按兴趣、能力、风险偏好和学习成本打分。这个过程中，AI 既是资料员，也是分析助手，还是原型工程师。
语言学习也类似。先明确目标：是为了旅游交流、考试，还是工作会议；再让 AI 生成分级词表、例句和听说练习；最后做一个简单单词卡应用，记录掌握程度。家庭预算则可以先分析账单数据，找出支出结构，再生成月度预算仪表盘，让每个月的变化更直观。
这些例子共同说明一件事：AI 的价值不只体现在某一次回答有多惊艳，也体现在它能参与从想法到作品的多个环节。Brainstorm、Research、Build、Share、Iterate，每一步都可以用提示词往前推一点，但每一步也都需要人来定方向、看结果、做取舍。
所以，千里之行仍从跬步开始。不要一上来就要求 AI “做一个完美产品”，先让它帮你澄清问题，整理材料，生成第一版，再拿真实反馈继续改。会问只是起点；能把 AI 放进真实流程里反复使用，才算真正把它用起来。
]]>文章千古事，得失寸心知。
杜甫这两句诗，写的是文章分量，也写的是作者责任。文字一旦落笔，辞藻是否漂亮不重要，重要的是观点是否成立、材料是否真实、结构是否清晰，以及读者读完后能否获得一点新的理解。
AI 出现之后，写作门槛看似降低了。只要输入一句“帮我写一篇文章”，几秒钟后就能得到一篇语气通顺的稿子。但“通顺”不等于“好”，完整不等于有价值。
很多 AI 文章的问题，恰恰不在语病，而在于太像一篇 “正确的废话” ：看上去什么都说了，细读却发现没有真正的思考。
所以，用 AI 写作，更合适的方式是先让它参与思考、谋篇、校订和审阅，别一上来就交给它代写全文。
好文章仍然需要人的经验、取舍和判断；AI 所能做的，是帮你厘清思路、搭稳结构、点出空泛之处，再将表达打磨得更为精准。
孔子说“辞达而已矣”，并非纵容文字粗糙，重点在于言辞须能达意。AI slop 的问题恰在于此：它往往有文章的形，却无清晰的意。
所谓 AI slop，是那种表面完整、读起来也顺，却内容空泛、缺少真实思考密度的文字。它往往塞满 “大趋势、赋能、重塑、提效、深度融合” 一类大词，段落之间也能接得上，可读者合上书页，却说不出究竟多知道了什么。
例如一篇谈 “AI 改变教育” 的文章，若从头到尾只在重复「AI 将推动个性化、促进教学创新」，却不交代老师在备课、批改、答疑里具体怎么用工具，也不触及学生依赖标准答案、数据隐私与评价公平等现实问题，那便只是套着文章壳子的泛泛表态。
这类文字通常有几个明显特征：大词多，事实少；形容词多，名词和动作少；结构套路化，动不动就是“首先、其次、最后”；句式像模板，尤其爱写“不是 X，而是 Y”；看似重要，却说不出具体发生了什么。
AI 为什么容易写成这样？因为它很擅长模仿文章外形。给它一个宽泛题目，它会从大量常见文本中归纳出最通用的写法：先定义问题，再列三点意义，最后升华一下。这样写可以很快凑出一篇 “像文章” 的东西；可若没有具体材料、真实场景和明确立场，落笔就只会滑向语料里最常见、最省事的那套说法。
更麻烦的是，AI 腔还会反过来影响人的表达。人用得多了，也可能开始模仿那些通顺但空洞的句式：动不动 “深入探讨”、 “多维赋能”、 “重塑格局”，写出来像正式文章，却少了自己的观察。用 AI 写作，首先要守住表意的精确，也要守住自己的经验和判断。
判断一段 AI 文字好不好，不能只看是否流畅，而要看信息密度。一段好文字应当让读者获得具体判断：谁在什么场景下遇到什么问题，为什么旧办法不好用，新办法解决了哪一部分问题，又留下什么风险。只要记住这个标准，很多“像文章”的段落会立刻现出原形。
操千曲而后晓声，观千剑而后识器。文章很少一次成形，通常要在反复推敲中慢慢长出来。
最平庸的提示，就是直接说：“请写一篇关于 AI 提高效率的文章。”AI 会照做，而且往往做得很快：开头谈时代背景，中间分三点讲工作、学习、生活，结尾呼吁拥抱变化。这样的稿子不一定有明显错误，但它很难留下印象，因为没有作者自己的观点和态度。
更好的流程，是把写作拆成几个阶段。先让 AI 生成多个大纲，再由人选择方向并修改结构；接着扩展为段落要点，补入自己的例子、材料；最后才进入正文生成并润色语言。这个顺序看似慢，其实更省力，因为先改大纲，比事后再一句一句修补的效率高的多。结构错了，句子再漂亮也救不回来；结构对了，哪怕初稿粗糙，也知道该往哪里改。
比如你想写“小团队如何使用 AI 提高效率”，不要急着让 AI 直接成文。可以先让它列出几种写法：一种从团队故事切入，一种按业务流程分析，一种专门讨论风险和边界。你读完之后可能发现，故事驱动型更适合公众号文章，分析论证型更适合内部分享，正反对比型更适合给管理层做决策参考。这个选择本身，就是写作中最重要的判断之一。
很多人用 AI 写文章，问题不在润色不够，而在太早开始润色。文章要回答什么问题、写给谁看、最重要的例子是什么，这些都还没想清楚，就急着让 AI 把句子改得“更优美、更有文采、更高级”。结果往往是文字顺了，文章还是空的。写作的第一步，是先把方向定下来，再去打磨句子。
《礼记》：“凡事预则立，不预则废。”写作中的“预”，就是先搭好结构。对 AI 写作来说，渐进式大纲往往是最省力、也最容易见效的方法。
不要让 AI 只给一个答案，可以先让它给出几种不同写法。这样可以避免一开始就被某一种结构带偏，也方便你比较不同写法的优缺点。一个题目如果只生成一版大纲，你很容易顺着第一版往下走；如果同时看到故事驱动型、分析论证型、正反对比型，就更容易判断哪种结构适合你的材料和读者。
可以这样提示：
我想写一篇文章，主题是“小团队如何使用 AI 提高效率”。
请给出 3 种不同结构：
1. 故事驱动型
2. 分析论证型
3. 正反对比型
每种结构列出段落标题、核心论点和适合使用的例子。
拿到结果以后，不要急着选一版照抄。更好的做法，是把几版大纲拆开来看：故事型的开头可能好，分析型的中段可能扎实，正反对比型的风险部分可能最有价值。你可以把不同方案里最有用的部分重新组合成自己的大纲，再让 AI 检查前后顺序是否顺畅。
在大纲阶段，还要主动加入取舍。比如一篇 2500 字的文章，不可能同时讲工具清单、组织流程、员工培训、数据安全和成本收益。你需要决定哪些是主线，哪些只能点到为止。这里可以让 AI 帮你做压缩，但最后要由你判断：这篇文章到底写给谁？读者读完后，应该改变哪个具体行为？
渐进式大纲的关键，是先比较结构，再扩写段落。这样做，AI 就不再是“代写者”，而更像一个帮你搭架子的助手。它负责多给几种思路，你负责判断方向；它负责补充角度，你负责确定主次。这样写出来的文章，才不容易变成那些谁都能说的套话。
兼听则明，偏信则暗。文章如果只顾着替一个观点叫好，很容易写成宣传稿。真正有分量的论证，往往要把反对意见摆出来，再逐一回应。
写 AI 提高效率，除了速度和便利，也要谈幻觉、隐私、依赖和信息污染。写远程办公，除了自由和省通勤，也要谈沟通成本、团队关系和边界感。
反对意见的价值，不在于让文章显得“客观”，而在于逼作者把论点说清楚。比如你主张“小团队应该尽快使用 AI”，读者真正关心的未必是 AI 能不能省时间，更可能是“会不会泄露客户资料”“员工会不会拿它敷衍工作”“生成内容出了错谁负责”。如果文章不回答这些问题，读者不会因为你多写几句“效率革命”就被说服。
可以这样要求 AI 帮忙：
请为这篇文章补充 3 个可能的反对意见，并说明如何回应。反对意见要写得真实、有道理，不要故意弱化。
这句里的“真实、有道理”很重要。弱化反对意见很容易，比如把反对者写成“害怕新技术的人”。可现实里的反对意见往往并不荒唐：数据安全确实重要，过度依赖确实会削弱判断，低质量内容确实会污染信息环境。文章需要说明边界：哪些任务适合用 AI，哪些必须人工复核，哪些材料不能上传，哪些输出不能直接发布。
能认真回应反对意见的文章，读者更容易相信。说服力不靠语气强硬，而靠把话说清楚：这个观点在哪些条件下成立，遇到哪些情况就要收住。
如切如磋，如琢如磨。写作越到后半程，越需要这样的细磨。相比从头开始，AI 更适合在你已有初稿之后，充当编辑和审阅员。
当你手里已经有一段真实文字，AI 反而更容易帮上忙。它不用凭空猜你的观点，可以围绕已有材料做判断：这一段是否啰嗦，论点是否清楚，例子是否贴合，语气是否过重，前后是否重复。此时的 AI 更像编辑，帮你把自己的声音修得更清楚。
使用时尽量分段处理，少让 AI 整篇重写。整篇重写很容易把个人表达洗成统一口吻，原本有辨识度的例子和节奏也会被抹平。更稳妥的方法是让 AI 只修改一段，并明确要求不要改变原意：
请只修改这一段，给我三个版本：
1. 更简洁
2. 更有论证力
3. 更口语但不轻浮
不要改变原意。
这类提示的好处，是把修改目标说清楚。“更简洁”就是删冗余，“更有论证力”就是补逻辑，“更口语但不轻浮”就是调语气。你不必一次接受全部修改，可以从三个版本里挑一句、改一个转折、保留一个更准确的动词。AI 给的是备选，不是定稿。
还可以让 AI 先看结构，再改句子。比如先问“这篇文章哪一节最弱，为什么”，再问“第二节哪些段落顺序可以调整”，最后才问“请润色这一段”。如果一开始就要求润色，AI 很可能只会把句子变得更圆滑，却不会指出文章真正不顺的地方。
把 AI 当编辑，还有一个好处：它不会疲劳。人修改自己的文章，很容易忽略掉重复、不连贯和空话；AI 可以反复按照同一标准检查。真正需要警惕的是，不要把它的改写照单全收。每次接受修改前，都要问一句：这句话有没有说得更精确，还是只是变得更像“正式文章”？
如果一篇文章很重要，也可以让不同模型交叉审稿：一个模型帮你生成或改写，另一个模型按评分标准挑问题。不同模型擅长的地方不完全一样，换一个模型看稿，有时能发现原模型自查时漏掉的问题。但这只是多一层参考，作者自己的判断不能外包。
“得失寸心知”，审稿的标准。不要问 AI “你觉得我写得怎么样”，这个问题太宽，AI 很容易给出礼貌而模糊的表扬。更有效的方法，是给它明确评分标准，让它按项检查。
可以使用一张简单 Rubric：
| 维度 | 分值 |
|---|---|
| 观点是否明确 | 20 |
| 结构是否顺畅 | 20 |
| 例子是否具体 | 20 |
| 是否处理反对意见 | 20 |
| 语言是否自然、有信息密度 | 20 |
然后这样提示：
请按以上标准逐项评分。先分析每一项，再给总分。最后列出最值得修改的 3 处。
评分标准的作用，不是简单让 AI 给文章打个分，重点是把修改方向说清楚。比如“例子是否具体”这一项得分低，就不要继续堆抽象论述，应该补一个真实场景：某个销售团队如何用 AI 整理客户邮件，省下多少时间，又在哪一步必须人工确认。再比如“是否处理反对意见”得分低，接下来该补的不是更强硬的语气，而是读者最可能提出的质疑。
Rubric 还能减少 AI 的迎合倾向。没有标准时，它可能会说“整体已经很好，只需稍作润色”；有标准时，它必须逐项说明问题。你甚至可以要求它更严格：
请以挑剔编辑的标准审稿。不要夸奖，重点指出逻辑跳跃、空洞表达和缺少证据的地方。
不过，评分只是工具，不是裁判。AI 可能指出问题，也可能误判你的风格选择。最终是否修改，仍要回到作者自己的判断。机器可以帮你看见盲点，取舍仍要由作者完成。
用 AI 写作，目标不该是让机器替你发声。更好的用法，是让它帮你理清思路、搭好结构、删掉空话。古人说“文章千古事，得失寸心知”，一篇文章是否成立，最后仍要回到作者心中：我是否真的有话要说，是否把这件事说清楚了，是否对读者负责。
]]>兼听则明，偏信则暗。
这句话讲的是听取意见的方式，用在 AI 上也很准确。很多人已经习惯让 AI 回答问题、整理资料、润色文字，却还没有真正把它当成“思维伙伴”来使用。所谓思维伙伴，绝不是替你拍板，也不是顺着你的想法溜须拍马，而是帮助你看见更多选项、拆开复杂权衡、发现被忽略的风险。
AI 很适合陪人想问题。它反应快，知识面广，能在短时间内提出多个角度；但它也有一个明显弱点：如果你问得太像寻求认同，它往往就会不加思考直接给你认同。比如你问“这个想法是不是很好”，它很容易顺着你说；你要求它比较、质疑、评分、找漏洞，它才更可能进入有价值的分析。
因此，这一篇要谈的不是“让 AI 给答案”，而是怎样让 AI 参与思考。真正高质量的用法，是让它生成多个方案，暴露权衡，指出风险，并在一轮又一轮反馈中逐步逼近可执行结论。
他山之石，可以攻玉。人在做决定时，最缺的常常不是信息，而是外部视角。我们会被已有经验牵着走，也会被眼前压力限制住想象。AI 的价值，正在于它可以快速把问题从一个角度扩展到多个角度，让你看到原本没有想到的路径。
比如购车，不只是比较品牌和价格，还涉及通勤距离、家庭人数、停车条件、保险、保养、贷款压力和未来几年是否会换工作。你单问“买哪辆车好”，AI 只能给出泛泛的推荐；但如果你把预算、使用场景、所在城市、家里是否有老人孩子、是否能安装充电桩讲清楚，它就能把问题拆成几个方案：省钱优先、空间优先、低维护成本优先、长期保值优先。
类似地，租房、搬家、还债、职业选择、学习计划、旅行安排，都很适合让 AI 参与前期思考。它可以先帮你列出变量，再把变量组合成方案，最后提醒你哪些地方还需要补充事实。AI 擅长扩展视野，但最终判断仍要由人负责。它能帮助你想得更全，却不能替你承担现实后果。
把 AI 当思维伙伴时，提问方式要从“给我答案”改成“帮我一起分析”。例如：
我正在考虑是否搬家。请先帮我列出需要考虑的关键因素，再给出 3 个不同取向的方案。不要急着推荐唯一答案。
这类提示的重点，是先打开问题空间。你不必一开始就知道自己想要什么，因为思考本来就是逐步澄清的过程。好的 AI 协作，不是一次问答结束，而是在对话中把模糊问题变成清楚问题。
乱花渐欲迷人眼，浅草才能没马蹄。第一次问 AI 时，答案常常像浅草：看得见形状，但还不够深。原因不神秘。AI 默认会输出训练数据里最常见、最安全、最容易被多数人接受的答案。它不知道你的真实限制，就只能先给一个平均答案。
最典型的例子是健身计划。你说“帮我制定一个健身计划”，常见结果大概率包括深蹲、俯卧撑、跑步、平板支撑和拉伸。这些动作没错，但它们可能完全不适合你：你也许膝盖不舒服，不喜欢深蹲；家里没有哑铃，却有一根弹力绳；每天只有 12 分钟，还希望孩子能跟着一起动一动。
当你补充这些限制之后，方案会立刻变得不同。AI 可能把跑步改成低冲击跳跃，把深蹲换成靠墙坐或臀桥，把单人训练改成亲子游戏式循环。变化不是因为模型突然“更聪明”，而是因为你把它从泛泛的搜索空间拉进了具体场景。
所以，第一次回答普通，并不等于这次对话失败。它常常只是一个草稿，一个可以批注的初版。限制条件不是创意的敌人，而是创意的入口。预算、时间、器材、性格、偏好、禁忌、已有资源，都会迫使 AI 生成更贴近现实的方案。
更好的做法，是把第一轮回答当作素材来反馈：
这个方案里我喜欢 12 分钟循环训练的结构，但不喜欢深蹲和跑步。请保留短时训练，改成对膝盖更友好、孩子也能参与的版本。
反馈往往比初始提示更有价值。因为人也不是一开始就知道自己要什么，很多偏好只有看到一个不够好的版本，才会变得清楚。
博观而约取，厚积而薄发。头脑风暴也是如此。先广泛展开，再收束选择；先允许多个可能，再进入执行细节。如果一开始就要求 AI 给“最佳方案”，它很容易过早收敛，给出一个看似明确、其实考虑不周的答案。
更稳妥的做法可以分六步：
这套流程在生活决策里很有用。比如债务还款，信用卡、学生贷款、亲友借款的压力并不一样。信用卡利率高，适合优先处理；学生贷款可能利率较低，但期限长；亲友借款未必有利息，却有情感压力。让 AI 只说“先还高利率债务”不够，你还需要它把财务成本和关系成本一起放进来比较。
搬家也是类似。一个方案可能租金低，但通勤增加 40 分钟；一个方案离学校近，却离医院和老人住处远；一个方案生活便利，但停车困难。AI 可以把这些变量列成矩阵，帮你看到每个选择牺牲了什么。旅行安排更是典型：同行人年龄、体力、天气、预算、景点开放时间和交通方式，任何一个条件变化，路线都可能要调整。
可以把高质量头脑风暴概括成这样一句话：
高质量头脑风暴 = 上下文 + 多方案 + 反馈 + 多轮迭代
这里最重要的是不要把第一轮当结论。第一轮负责打开可能性，第二轮负责吸收反馈，第三轮以后才适合进入日程、预算、清单和分工。AI 的优势不是“一句话猜中你要什么”，而是能承受多轮修改，并在每轮里保持结构化思考。
操千曲而后晓声，观千剑而后识器。
复杂任务需要时间换质量。简单事实可以快速回答，比如“这个词是什么意思”“这段话有没有错别字”；但多约束、多目标、多文档的问题，如果要求 AI 秒回，结果往往只能停留在表面。
买车决策就是一个典型复杂任务。车价只是第一层，后面还有保险、贷款利率、维修成本、保值率、家庭成员使用场景、停车条件，以及未来三五年的收入稳定性。你让 AI 快速推荐车型，它可能给出几款热门车；你让它先分析权衡，再比较方案，它才可能把“买得起”和“养得住”分开讨论。
旅行计划也一样。罗马一日游不是简单把斗兽场、梵蒂冈、许愿池塞进一天。景点开放时间、排队长度、彼此距离、同行人体力、是否带孩子、午餐位置、天气和交通罢工，都可能影响路线。如果 AI 只是按热门程度把景点排在一起，行程表看着充实，真正走起来却可能很累。
因此，面对复杂任务，可以明确要求 AI 放慢节奏：
请先分析目标、限制和主要利弊，再给建议。不要直接给结论。请指出哪些信息不足，以及这些不确定性会如何影响判断。
这不是迷信“深度思考”四个字，而是把回答顺序改掉。先分析，再建议；先列不确定性，再给结论。过去很多提示词会写“一步一步思考”（CoT，思维链），现在更实用的是表达高层意图：请认真权衡、请充分分析、请先找出缺口再回答。当你让 AI 解释理由、比较选项、说明失败条件，它就更难只给一段顺滑但空泛的话。
当然，也不必所有问题都让 AI 长篇分析。问一句常识，快速回答就好；涉及金钱、时间、家庭、职业或长期承诺的问题，才值得要求它多花几步推理。工具的使用强度，要和问题的重要性匹配。
《论语》：“众恶之，必察焉；众好之，必察焉。”别人都说不好，要仔细看；别人都说好，也要仔细看。AI 经过人类反馈训练，往往倾向于给出让用户满意的回答。这有助于对话友好，却也可能让它变成应声虫。
如果你问“这个方案是不是很优秀”，AI 很可能会先肯定你的思路，再补几句温和建议。你问“远程办公是不是效率更高”，它可能顺着“效率更高”来组织理由。你问“帮我找出这个商业点子的亮点”，它就会努力找亮点，哪怕这个点子真正需要的是冷静分析、仔细拆解。
问题不在于 AI 故意讨好你，而在于你的提问已经把方向写进去了。带有强烈预设的问题，会把回答推向预设结论。想要得到批判性分析，就不要把结论藏在问题里。
更好的问法，是要求它同时看正反两面：
请从成本、风险、收益、执行难度四个方面评估这个方案。
请比较远程办公和办公室办公的优劣，分别说明适合和不适合的团队类型。
请指出这个商业点子的优势、漏洞和最可能失败的原因。
这些问法把 AI 从“讨好我”拉回到“审查问题”。尤其是商业决策、职业选择、投资、合同、健康和家庭安排，最危险的不是 AI 说错一句事实，而是它用流畅语言强化了你原本就想相信的判断。遇到重要问题，要主动要求它说难听话：哪里不成立，哪里成本被低估，哪里最容易失败。
规矩，方圆之至也。评价问题最怕凭感觉。你说“帮我看看哪个方案更好”，AI 很容易给出一个听起来合理的综合判断，但你未必知道它到底把什么看得更重。Rubric 的作用，就是把“好不好”拆成明确的评价标准。
Rubric 可以理解为评分表。它把一个模糊判断拆成几个维度，并给每个维度设置权重。比如评价搬家方案，可能需要考虑通勤时间、房租压力、孩子教育、医疗便利和生活舒适度。每个家庭看重的东西不同，权重也应该不同。
| 维度 | 权重 |
|---|---|
| 通勤时间 | 25 |
| 房租压力 | 25 |
| 孩子教育 | 20 |
| 医疗便利 | 15 |
| 生活舒适度 | 15 |
有了 Rubric，提示就可以这样写：
请先逐项评分，再汇总总分。不要先给结论。每项必须说明理由，并指出最主要的不确定性。
这句提示里有三个关键动作。第一，先逐项评分，避免 AI 一上来凭整体印象下判断。第二，说明理由，让每个分数都有依据。第三，指出不确定性，提醒你哪些信息还没查清。Rubric 的价值不是让 AI 变成裁判，而是让判断过程透明化。
例如两个搬家方案总分相近，一个赢在房租低，一个赢在学校近。没有 Rubric 时，你可能只看到“推荐方案 A”；有了 Rubric，你能看到 A 的代价是通勤更长、老人就医不便，B 的代价是房租压力更高。此时真正有价值的不是总分，而是分数背后的取舍。
AI 可以是谋士，也可以只是应声虫。差别不只在模型有多聪明，更在于你是否要求它看见反面、比较选项、说明理由，并接受你一轮又一轮的追问。让 AI 成为思维伙伴，关键不是让它替你想，而是让它帮助你把问题想透。
]]>工欲善其事，必先利其器。
上一篇我们谈了 AI 的知识边界：它读过很多公开资料，却不等于知道当下世界的一切；它能快速组织答案，却会受知识截止、来源质量和上下文不足影响。知道这些之后，下一步就很自然了：如果想让 AI 真正帮上忙，我们不能只把问题丢过去，还要学会给它准备材料。
这就是“上下文工程”。
所谓上下文工程，听起来像一个很技术的词，实际讲的是一件朴素的事：把任务背景、目标、材料、约束、受众和输出要求交代清楚。AI 像一位聪明但不熟悉你处境的同事，你给它的信息越具体、越相关，它越能产出可用结果；你只给一句含糊的要求，它多半只能用模板补空。
很多人第一次用 AI 写东西，喜欢直接说：“帮我写一份年终总结。”AI 很快就能写出一篇：开头感谢团队，中间罗列成长，结尾展望未来。看起来完整，读起来顺滑，但你仔细一看，会发现它和你这一年做过什么关系不大。
原因很简单：巧妇难为无米之炊。它不知道你的岗位，不知道你做过哪些项目，不知道哪些成果最重要，不知道这份总结是给直属领导还是未来面试官看。信息缺失时，AI 只会用最常见的表达方式去生成。
同样的问题也会出现在求职信、学习规划和商业方案里。你说“帮我写求职信”，AI 不知道岗位 JD、你的经历、公司业务和你想突出的能力。不是 AI 不会写，而是你没有把它写好所需的材料交给它。
所以，提示词质量的核心不在于词句是否漂亮，而在于信息是否充分。输出质量的上限，往往由输入质量决定。当你只给一句短提示，AI 只能交出一份“像样”的结果；当你给出具体背景、真实材料和明确要求，它才有机会交出一份“像你”的结果。
《礼记》：“凡事预则立，不预则废。”与 AI 协作也是如此。所谓上下文，就是 AI 在生成回答时可以使用的全部信息。
它不只是你当前输入的那一句话，还包括你上传的文件、图片、表格、音频，也包括当前对话里前面说过的话。有些工具还可以读取指定文件夹、网页、代码仓库或系统环境，这些也会成为上下文的一部分。简单说，凡是 AI 能拿来理解任务的信息，都属于上下文。
这也是 AI 和传统搜索框很不一样的地方。搜索框通常只处理几个关键词，而 AI 可以把一段对话、几份文件、几张截图和一组约束放在一起理解。
人的工作记忆很有限，购物清单一多就容易漏；AI 的上下文窗口却能容纳很长的材料，这让它适合做跨文件整理和综合分析。比如你想在物理和动物学两个专业之间做选择，单问“学物理还是动物学更好”，答案一定泛泛而谈；但如果你补充自己的课程成绩、兴趣测评、未来职业偏好、家庭预算和所在学校课程安排，AI 才能给出更贴近你的分析。
不过，上下文不是越多越好。真正有用的是足够且相关的信息。把所有材料一股脑塞进去，可能让 AI 迷失重点；只给一句口号，又会让它无从下手。
好的上下文，像给顾问准备材料：既不能藏着关键信息，也不能用无关细节淹没问题。
《中庸》：“博学之，审问之，慎思之，明辨之，笃行之”。给 AI 准备上下文，也需要这几层功夫。这里先抓最实用的三个标准：相关、具体、可验证。
第一，相关。只提供和任务直接有关的信息。无关材料会污染答案。比如你前面一直在和 AI 讨论自己的健身计划，包括体重、训练习惯和伤病情况，接着突然说“帮我妈妈也做一个计划”，AI 可能会把你的信息误带进去。这个时候，最好明确说明对象变了，或者直接开新对话。
第二，具体。少说“帮我优化”，多说“优化给谁看、用于什么场景、希望达到什么效果”。比如这句就比“改一下求职信”好得多：
请把这段求职信改得更适合投递数据分析岗位，语气专业但不要夸张，突出我做过的销售数据看板项目。
第三，可验证。尽量提供事实、数据、原文，而不是只提供感受。你让 AI 分析租房合同，上传合同原文一定比口头描述更可靠；你让它做家庭预算，提供真实账单分类一定比说“我感觉最近花钱有点多”更有用。
这三个标准可以合成一句话：给 AI 的不是情绪化愿望，而是可使用的材料。材料越清楚，AI 越能把能力用在解决问题上，而不是用在猜测你的真实需求上。
上下文有用，但也有副作用。AI 会把当前对话里的信息当作背景继续使用，这在同一个任务中是优势，在切换任务时却可能变成干扰。
长对话很适合持续迭代同一件事。比如你让 AI 帮你写一篇文章，先讨论主题，再改大纲，再扩写段落，再调整语气，这些前文都会成为后续修改的依据。它会逐渐“知道”你偏好什么，不喜欢什么，哪些例子已经用过，哪些观点需要保留。
但如果话题变了，旧上下文就可能污染新任务。你刚让 AI 给自己做理财计划，里面有收入、风险偏好和贷款情况，接着又问“帮我爸妈规划养老资产”，如果不说明对象变了，它可能会混用前面的信息。你刚给 A 公司写完求职信，又在同一对话里给 B 公司写，如果不明确区分，两份材料也可能串味。
因此，管理上下文要有一个简单习惯：同一任务可以长聊，新任务最好重开。尤其是涉及财务、健康、法律、合同、求职这类高风险或高度个人化的任务时，要么开新对话，要么明确告诉 AI：“忽略前面的个人背景，下面是一个新对象。”
会用上下文，不只是会加材料，也包括知道什么时候该清空材料。
过去使用 AI，多数时候是用户手动喂资料：复制一段文字，上传一个文件，说明几条背景。现在，越来越多桌面 AI 和 Agent 工具可以主动读取文件夹、浏览项目资料、整理目录、生成计划，甚至执行写入、移动、重命名等文件操作。
这是一种很重要的变化。传统聊天模式里，上下文主要由你选择；Agent 模式里，AI 可以按任务需要自己去找资料。比如你说“帮我整理这个研究资料文件夹”，它可能先查看文件类型，再按主题、时间或项目阶段提出分类方案。你说“帮我安排本周拍摄计划”，它可能读取拍摄说明、成员日程、场地信息，再整理出执行表。
能力变强之后，风险也会变强。读取文件意味着它可能看到敏感信息；写入和移动文件意味着它可能真的改变你的工作区；删除、覆盖、批量重命名，更是可能造成难以恢复的损失。有些工具的文件操作不一定经过回收站，也不一定有完整版本历史，所以不能把 Agent 的执行权限当成普通聊天权限来看。
所以，Agent 场景下要守住三条原则：
换句话说，AI 可以替你找材料、整理材料、处理材料，但授权边界必须由人来定。让它做助手，不要让它在你没看清方案之前接管现场。
讲到这里，可以把上下文工程简化成一个通用模板。当然，它不是什么万能咒语，而是一张检查清单，帮助你在提问前把事情交代明白。
背景：我正在……
目标：我希望得到……
材料：请参考……
受众：这份输出给……
约束：不要……必须……
输出格式：请用……
评价标准：请重点考虑……
比如你要让 AI 帮你改一份求职信，可以这样写：
背景：我正在申请一家 SaaS 公司的数据分析岗位。
目标：请帮我优化求职信，让它更突出岗位匹配度。
材料：下面是岗位 JD 和我的原始求职信。
受众：招聘经理和未来直属主管。
约束：不要夸大经历，不要使用空泛形容词。
输出格式：先指出 3 个主要问题，再给出修改版。
评价标准：重点看是否突出数据分析能力、业务理解和项目成果。
这个模板的价值，不在于每次都要完整填写七项，而在于提醒你：提示词的本质不是把话说得玄，而是把事情交代明白。背景不清，AI 就只能猜；目标不清，AI 就只能泛泛而谈；评价标准不清，AI 就不知道什么叫“好”。
上下文准备得越好，后面的生成、推理、修改和评估越省力。到了下一篇，我们就可以在这些上下文的基础上，把 AI 从“回答问题的人”进一步变成“参与思考的人”。
]]>纸上得来终觉浅，绝知此事要躬行。
陆游这两句诗，用在学习 AI 上也很贴切。许多人一开始接触 AI，容易把它当成一部无所不知的百科全书：问一句，它答一句；答得流畅，就默认可信。可真正用久了才会发现，AI 的本事并不神秘，它的强处和短处都有迹可循。
它有时像读书破万卷的助手，能迅速解释生活常识、历史典故、科学概念；有时又像翻着旧书找答案的学生，对最新消息、小众事实、专业细节把握不稳。要用好 AI，第一步不是急着学习提示词模板，而是先弄清楚：它的知识从哪里来，什么时候会过时，什么时候需要搜索，什么时候值得做更深入的研究。
这一篇先从“知己知彼”开始。只有知道 AI 何以聪明、何以糊涂，我们后面谈上下文、提示词、写作和多模态应用，才不会变成空中楼阁。
AI 的“源头活水”，首先来自预训练。所谓预训练，可以粗略理解为：模型在正式与你对话之前，已经读过海量文本，包括互联网网页、百科、书籍、新闻、论文、论坛、问答社区和各类公开语料。它正是在这些材料中学习语言如何组织、概念如何关联、问题通常如何被回答。
这也是为什么 AI 常常显得“什么都懂”。你问它手机进水怎么办，它大概率会提醒你立刻断电、擦干、不要开机、尽快送修；你问某个广为人知的科学或历史常识，它也能很快组织出答案。这些问题之所以容易回答，并不是因为 AI 正在现场观察世界，而是因为类似信息在公开文本中出现得足够多。
所以，理解 AI 的第一条原则是：它的可靠性与训练数据的分布密切相关。常见主题、稳定知识、反复被讨论的问题，通常更容易得到靠谱回答。比如烹饪、电影、科学概念、历史人物，AI 往往能给出结构清楚、细节也还过得去的解释。
反过来，如果一个问题在公开语料中很少出现，或者只存在于很小的圈子里，AI 就容易不稳。冷门概念、小众活动、公司内部制度、私人合同条款，都不该默认它知道。你问“某个小众山地活动的由来”，它可能需要搜索；你问“我们公司今年的报销规则”，如果没有提供制度文件，它只能猜；你问一份租房合同里某个特殊条款如何理解，最好的做法是把合同原文交给它，而不是让它凭常识发挥。
语言分布也会影响答案质量。像 ChatGPT 这类大模型读过的英文资料通常更多，因此在英文世界里被充分讨论过的问题，知识覆盖往往更厚；而对于一些中文地方性表达、方言、小语种材料或本土行业细节，模型可能会更依赖有限材料。它不是不能回答，而是回答时更需要你提供背景、原文和判断标准。
因此，不要把 AI 的流畅回答误认为真实世界本身。更准确的理解是：AI 像一个读过很多公开资料的助手，擅长在常见知识和语言模式中快速组织答案；但它没有天然通向私有信息、冷门事实和最新变化的神通。遇到常见、稳定、低风险的问题，可以直接问；遇到冷门、隐私或会变化的问题，就要准备更多上下文，或者进入下一步：让它搜索和验证。
及时当勉励，岁月不待人。知识也是如此。
预训练让 AI 拥有一套广泛的基础知识，但这套知识并不会自动随着现实世界每一天的变化而更新。模型训练在某个时间点结束，它对世界的“记忆”也会在那个时间点附近冻结。之后发生的新事件、新政策，模型默认并不知道。
这就像家里有一套很厚的百科全书。它内容丰富，解释经典概念没有问题；但你不能指望它告诉你今天哪家餐厅还在营业、某款手机此刻的最低价、或者最近网上流行的梗到底从哪来。不是书不好，而是问题本身要求“现在”的信息。
判断一个问题是否可能“过期”，可以看它是否带有时间、地点和状态变化。比如“附近哪家餐厅评分高”“今天适不适合去公园露营”，这些问题都不适合只靠模型记忆。评分会变，天气会变，事情也会变。
相反，一些稳定知识通常可以直接问。比如“为什么水烧开会沸腾”、“简历里项目经历应该怎么写得更清楚”，这些问题不依赖实时状态。即使没有搜索，AI 也能基于已有知识给出有用答案。
所以，使用 AI 时可以先在心里问一句：这个答案会不会随着时间变化？如果不会，直接问通常足够；如果会，就要提醒 AI 搜索最新资料，或者自己提供最新文件和链接。知识截止并不可怕，可怕的是把会变化的问题当成不会变化的问题来问。
不过，搜索并不等于万无一失。它能让 AI 临时翻阅现实世界的新材料，却也会带来另一个问题：新材料本身是否可靠？这就进入下一节。
尽信书，则不如无书。
Web 搜索能弥补知识截止，让 AI 接触到更新的信息，但它并不能保证搜到的每一页都可靠。互联网不是一座只收藏经典的图书馆，它更像一条热闹的街市：有官方公告，有学术论文，也有论坛闲聊、灌水软文。
因此，搜索让 AI “看见当下世界”的同时，也会把当下世界的杂质一起带进来。比如你问某种保健品、药物是否安全，如果 AI 随手抓到的主要是商家页面和用户评论，答案就可能有失偏颇，甚至包含错误信息。它可能总结了很多人的说法，却没有真正回答“这些说法有没有证据”。
还有一种更隐蔽的问题：AI 的搜索过程并不总是等同于人完整阅读原网页。很多时候，它会先由搜索系统找到网页，再提取摘要，最后让对话模型基于摘要组织答案。这个流程效率很高，但也可能带来偏差：网页本身没错，摘要可能漏掉限定条件；引用来源存在，解释却被说歪了。于是你会看到一种危险的答案：链接看起来正规，结论却未必严谨。
解决办法不是不用搜索，而是学会约束搜索。凡是涉及健康、药品、法律、金融、政策等高风险问题，都不要只说“帮我查一下”。更好的问法是直接指定来源质量：
请进行网页搜索，但优先参考官方机构、权威组织、同行评议论文或原始法规文件。
请区分事实、来源观点和你的推断。
如果来源之间有冲突，请列出冲突点，不要直接给单一结论。
这类提示的作用，是把 AI 从“谁声音大就总结谁”拉回到“谁证据强就参考谁”。例如判断药品安全性，可以要求优先参考监管机构、医院系统、医学论文，而不是销售页面；了解签证或税务政策，可以要求优先查看官方政府网站，而不是旅行博客；比较产品价格，可以要求说明搜索时间和来源平台，而不是只给一个孤零零的数字。
最后还有个保底的办法：重要信息自己点开原文看一眼。AI 很适合替你收集线索、整理差异、提炼重点，但它不应该替你承担所有判断责任。搜索解决的是“有没有新资料”的问题，辨别来源解决的才是“这些资料值不值得信”的问题。
这里也能看出 AI 和传统搜索引擎的分工。你要找某个官网、下载页面、商品链接，搜索引擎通常更直接；你要比较几份资料、归纳不同观点、形成一份带取舍的说明，AI 更有优势。前者擅长定位原始信息，后者擅长整合与解释。真正稳妥的做法，是让 AI 帮你整理线索，再在关键处回到原始来源核查。
操千曲而后晓声，观千剑而后识器。有些问题，不是查到一两个网页就能回答的。它们需要比较多个来源，拆分多个维度，识别相互冲突的信息，再把证据、限制和取舍合在一起看。这个时候，普通 Web 搜索就显得太薄，深度研究才更合适。
普通搜索擅长回答单点问题。比如“这周天气如何”、“店铺今天是否营业”，核心是找到较新的事实。深度研究面对的则是另一类问题：天气、预算、同行人的年龄、交通方式、节假日人流、酒店位置，会如何共同影响一次旅行安排？这就不是“查一个答案”，而是 “做一轮分析”。
深度研究的工作方式更像研究助理。它通常会先把问题拆开，判断需要哪些信息；再围绕不同方向多轮搜索，筛选来源，补充缺口；最后把材料整理成结构化报告。比较好的深度研究，不是上来就写结论，而是先给出研究计划，让你有机会检查方向是否跑偏。这个过程会更慢，可能需要几十秒到几分钟，但换来的是更完整的视野。
生活里适合深度研究的场景很多。比如你要给一家人规划假期旅行，普通搜索能告诉你某地天气和机票价格，深度研究则可以进一步比较路线、预算、老人孩子体力、交通方式和备选方案。再比如你想判断“每天走一万步是否真的有必要”，普通搜索可能给你几篇健康文章，深度研究则应该比较医学研究、年龄差异、运动强度、伤病风险和长期坚持的现实难度。
但深度研究也不是越多越好。它适合复杂、重要、需要权衡的问题，不适合替代所有查询。问“明天会不会下雨”，不必动用深度研究；问“今年暑假带父母和孩子去哪里更合适”，就值得让 AI 多花些时间。关键不在于把工具用得多复杂，而在于问题本身是否值得这么处理。
可以用一个简单标准判断：如果答案只需要一个事实，用搜索；如果答案需要多项事实之间的关系，用深度研究。前者解决 “是什么”，后者解决 “如何看、怎么选、为什么这样选”。
《大学》：“物有本末，事有终始，知所先后，则近道矣。”用 AI 也是如此。很多回答质量不高，并不是因为提示词不够花哨，而是从一开始就选错了信息路径：该凭常识时大动干戈，该查资料时闭门造车，该深入研究时又贪图秒回。
可以把 AI 的信息能力分成三层。
第一层，是预训练知识。它适合常识、稳定知识和低风险问题，速度最快。比如解释一个概念、整理一段文字、给出常见故障的处理思路，通常可以直接问。这里要利用的是 AI 已经“读过很多书”的优势。
第二层，是Web 搜索。它适合最新、本地、动态变化的信息，比如天气、价格、政策、营业时间、评分和新闻。这里要利用的是 AI 临时查资料的能力，同时记得约束来源，别让论坛闲聊和商业软文替你做判断。
第三层，是深度研究。它适合复杂分析、重大决策和多来源整合，比如旅行规划、职业选择、行业调研。这里要利用的是 AI 拆问题、找资料、做权衡的能力，但也要接受它需要更长时间。
下次提问前，可以先问自己三个问题：
这就是“知其先后”。会用 AI 的第一步，不是写出漂亮提示词，而是先判断问题属于哪一类。问题分清了，后面的上下文、提示词和工具选择才有着力点。否则，再长的提示词也可能只是把错误方向说得更详细。
]]>学而不思则罔，思而不学则殆。
既要思考，因为 prompt 是一套组织问题、引导思考的方法论。
又要学习，因为 agent 是一套需要理解和反复练习的高级工具。
短短一年时间，AI 工具从新鲜玩具迅速变成了日常工具。许多人已经会打开 ChatGPT、Claude 或 Gemini，找它帮忙“帮我写一份总结”，或是“帮我想几个方案”。
可真正用下来，又常常觉得结果时好时坏：有时像得力小助手，有时却像死板机器人；有时画龙点睛，有时满纸荒唐。
问题往往不在于是否拥有一份“万能提示词”模板，而在于我们还没有真正理解 AI 的工作方式。
AI 不是许愿池里的王八，也不是传统搜索框。它更像一位聪明但不熟悉你处境的同事：你给它清楚的背景、材料、标准和反馈，它就能帮你把事情向前推进；你只丢给它一句含糊的要求，它多半只能交出一份像样但普通的答案。
本专栏面向已经接触过 AI 工具，但仍停留在“随手问一句、碰碰运气”阶段的读者：从这里开始，理解 AI 的知识来源和边界，学会提供上下文，学会引导推理与批评，学会把 AI 用在写作、研究、图像、数据和应用构建中。
本专栏分为五篇，关系可以看作一张由内向外展开的地图：先建立认知，再组织输入；先提升思考，再打磨表达；最后把方法迁移到更多媒介和任务中。
| 学习阶段 | 对应文章 | 要解决的问题 | 与下一篇的关系 |
|---|---|---|---|
| 认识边界 | 《知己知彼，方能善用 AI》 | 明白 AI 的知识从哪里来，为什么会过时、出错或需要搜索。 | 只有知道 AI 的边界，才知道该补什么材料。 |
| 喂好材料 | 《巧妇难为无米之炊：上下文工程入门》 | 学会提供背景、目标、文件、图片、约束和输出要求。 | 有了上下文，AI 才能参与更复杂的思考。 |
| 引导思考 | 《不做应声虫：让 AI 成为真正的思维伙伴》 | 让 AI 帮你生成方案、比较权衡、指出风险，而不是迎合你。 | 会引导思考之后，才能避免写作中的空话和套话。 |
| 打磨表达 | 《文章千古事：如何用 AI 写出不像 AI 的文字》 | 用 AI 搭大纲、改段落、做审稿，写出有信息密度的文字。 | 写作方法再往外扩展，就进入图像、数据、代码等多模态任务。 |
| 扩展成事 | 《从一言到万象：多模态、数据与应用生成》 | 把提示词方法用于看图、读表、生成图像、分析数据和构建小应用。 | 这是前四篇方法的综合应用，也是从“会问”走向“会做”。 |
本专栏最想说明的一点是：用好 AI，靠的不是收藏多少提示词模板，而是掌握一套与 AI 协作的基本功。模型固然重要，但同一个模型，面对不同的问题组织方式、不同的上下文质量、不同的评价标准，输出会有天壤之别。
因此，真正值得练习的不是“怎么问一句神奇的话”，而是怎么把任务讲清楚，怎么把资料交完整，怎么让 AI 先分析再生成，怎么要求它指出风险，怎么在一轮又一轮反馈中把结果磨到可用。
当这些动作变成习惯，AI 的角色也会发生变化。它不再只是回答问题的机器，而会成为资料员、编辑、顾问、研究助理、数据分析助手，甚至是把想法变成作品的合作者。
鱼会吃完，渔法可以反复使用；本专栏要讲的，正是这套渔法。
]]>