一场没人提出异议的启动会，可能埋着四套互相冲突的项目范围。
AI项目启动会上，最让人放心的画面是什么？
老板讲完目标，业务补充场景，产品画出流程，技术点头，供应商说"没问题"。会议按时结束，每个人都觉得方向已经对齐。
两周后，气氛开始不对。
客户说："我以为Agent能自动处理。"
交付团队说："我们理解的是生成建议，由人工确认。"
业务说："边界早就讲过了。"
技术说："你们讲的是业务边界，我们问的是系统权限。"
没人撒谎，也没人偷懒。大家使用了同一组词，却把不同范围装进了词里。
AI项目大量返工，往往从这种"假装已经听懂"的时刻开始。
同一个词，每个人脑中装着不同大小的盒子
"边界"是一个典型例子。
业务人员说边界，可能指AI回答哪些客户问题，遇到哪些情况转人工。
产品经理说边界，想到的是流程从哪里开始、在哪里结束，以及谁接收下一步任务。
技术人员说边界，关心系统能访问哪些数据、可以调用哪些接口、能否写回生产系统。
管理者说边界，还包括错误由谁负责、预算覆盖到哪里、上线后谁继续维护。
四个人都说得对。颗粒度没有对齐，他们讨论的却不是同一个项目。
这种摩擦与能力高低关系不大。一个人长期工作在战略层，会习惯看系统和长期能力；另一个人负责具体交付，会把注意力放在当周能完成的流程。双方都用"边界"概括自己的问题，于是互相觉得对方说得太虚，或者看得太浅。
就像客户说想买一辆"好车"，销售开始讲发动机和底盘，客户心里想的只是空间大、开起来安静、预算不超过二十万。
术语没有翻译成场景和结果，专业知识越多，讨论越容易沿不同方向加速。
*图：工具、流程、系统和责任都可以被称为"边界"，但它们解决的是不同问题。*
AI新词，给模糊需求披上了专业外衣
Harness、Agent、RAG、工作流、多模态、知识库……AI行业每天都在制造新词。
这些词有技术价值。进入商务沟通后，它们也很容易变成一种方便的占位符。
老板说"做一个Agent"，可能希望员工少做一半重复工作；业务部门理解成一个能查询资料的聊天入口；产品团队开始设计多步骤任务流；技术团队则在评估自主决策、工具调用和状态管理。
同一句需求，成本可能从一周配置变成半年建设。
"工程化"也常出现类似错位。
对供应商而言，工程化可能包括权限、日志、监控、版本、评测和异常回退。客户听到的却可能是"从Demo变成一个可以登录使用的页面"。
"交付"更危险。
有人认为能演示就算交付，有人要求完成部署和培训，有人期待业务指标改善，还有人默认供应商长期维护知识库。
如果合同只写"完成企业知识库和智能问答Agent"，后面每一项都可能变成争议。
术语让会议听起来更专业，却不能替代范围、责任和验收证据。
项目启动前，先做一张关键术语卡
AI项目不需要编一本行业词典。团队只要挑出会影响预算、范围和责任的高频词，逐个写成可执行约定。
一张术语卡包含五项信息。
**术语名称**
写下项目里正在使用的词，例如Agent、自动化、知识库、边界、上线、交付。
**使用场景**
说明这个词出现在哪个业务动作里。脱离场景的定义容易重新变成概念解释。
**包含范围**
列出项目确定会完成的动作、系统和输出。尽量使用可观察的动词，例如读取、生成、提醒、提交、写回。
**排除范围**
明确本期不做的内容。排除项通常比宏大目标更能降低返工。
**验收证据**
说明用什么证明已经完成：测试样本、操作记录、接口回读、业务指标，还是责任人签字。
*图：术语进入项目文件时，要同时带上场景、范围和验收方式。*
举个例子。
术语写"自动回复"。使用场景是售后客服收到物流查询。包含范围是读取订单状态、生成回复草稿、标注来源，由客服确认后发送。排除范围是退款承诺、价格补偿和主动外发。验收证据是用五十条脱敏历史问题测试，检查引用准确率、转人工规则和人工确认记录。
这样一写，团队马上知道要准备哪些数据、接什么接口、谁负责验收。是否采用Agent反而变成后面的技术选择。
四个高频词，可以这样对齐
**Agent**
不要只问"是不是Agent"。说明它能自主决定哪些步骤，可以调用哪些工具，执行前是否需要确认，失败后如何停止。
**知识库**
说明资料来源、有效版本、使用权限、更新负责人和冲突处理方式。上传一批文件只是初始化动作。
**边界**
分别写业务范围、数据范围、动作权限和责任范围。一个"边界清晰"覆盖不了四项约定。
**交付**
写明最终产物、部署环境、培训安排、维护周期和验收指标。页面可用、系统上线和业务改善属于不同层次的交付。
一场30分钟的术语对齐会怎么开
这场会不需要做成培训。
前五分钟，每个人独立写下项目中最容易产生歧义的三个词。
接下来的十分钟，把重复最多的词贴到白板上。业务、产品、技术和供应商分别用一句话写出自己的理解，暂时不争论谁更标准。
再用十分钟讨论差异。每个词都要落到场景、包含范围、排除范围和验收证据。无法当场确认的内容，指定责任人和截止时间。
最后五分钟，把结果放进需求文档、合同附件或项目纪要。术语表需要版本号，范围变化时同步修改。
会议结束后，团队至少应该能补完一句话：
在【业务场景】中，我们说的【术语】具体包含【动作与范围】，不包含【排除项】，最终通过【证据】验收，由【角色】负责。
如果一句话仍然需要大量解释，颗粒度还没有对齐。
回归业务常识，不等于排斥技术
有些人听到"别扯概念"，会理解成技术不重要，随便找个工具试试就行。
这种做法同样会制造风险。
业务常识要求团队先回答几件朴素的事：谁遇到了什么问题，现在损失了多少时间或机会，AI介入哪一步，结果由谁检查，做错后能不能撤回。
答案清楚以后，再决定需要一个简单提示词、一个规则工作流，还是完整的Agent系统。
最轻的方案也应保留数据权限、人工确认和失败回退。轻量试验的意义是尽快获得证据，并非省掉必要控制。
AI应该减少重复劳动、缩短等待时间、帮助业务增长。如果一个项目让员工多维护三套资料、多填两张表、还要每天替系统收拾错误，团队有必要重新检查方案是否选错了问题。
专业沟通的价值，是让不同的人做出同一个动作
项目里最危险的词，往往人人都熟悉，熟悉到没有人继续追问。
Agent、边界、上线、交付听起来都很清楚。等到它们被翻译成数据、权限、动作、责任和验收，团队才拥有同一份项目范围。
颗粒度对齐不会降低专业度。它能让战略语言落到执行动作，也让技术方案回到业务结果。
下一场AI项目启动会，如果所有人一直点头，可以暂停五分钟，请每个人写下"我们说的Agent具体会做什么"。答案摆在一起，往往比再听一小时概念介绍更能决定项目能否按时交付。