一人公司建立AI交付质检表：从事实、格式到客户目标逐项复核

摘要

一人公司用生成式AI交付文案、分析、设计或代码时，真正危险的不是漏看错别字，而是输入版本、事实依据、客户目标、格式要求和敏感信息同时失控。文章将这些风险拆成“输入—目标—事实—格式—风险—责任”六道关卡，并提供可复制的交付前检查表与人工复核节点。如何在有限时间内守住验收与责任边界？

— OPCboot

使用生成式 AI 做文案、分析、设计或代码交付时，最容易出问题的不是“有没有通读一遍”，而是通读时没有固定标准：事实错了、输入缺了、格式不符、方案没有对应客户目标，甚至把敏感资料原样交给了工具。对一人公司来说，交付前质检应当从凭感觉阅读，改成一套可重复执行的流程。

这份框架不评价某个具体模型“聪不聪明”，也不承诺完全消除 AI 错误。它的作用是把容易遗漏的检查点固定下来，让你在有限时间内优先发现会影响客户验收、业务结果和责任边界的问题。

先确定：这份交付到底要通过什么验收

质检不是单纯找错别字，而是判断交付物是否满足约定。开始检查前，先把客户需求压缩成一张“验收基准卡”。

项目	要回答的问题	示例
交付物	最终要交什么	一份公众号文章、一个分析表、一个网页原型
使用对象	谁会使用或阅读	客户管理层、销售团队、终端用户
核心目标	客户希望改变什么	提高咨询转化、减少人工整理时间
必须包含	哪些内容不能缺	数据来源、行动建议、指定字段
必须避免	哪些内容不能出现	未证实结论、客户内部信息、夸大承诺
格式要求	以什么形式交付	Word、表格、代码仓库、指定字数
验收标准	客户如何判断合格	能直接发布、能运行、能被团队复用
截止与版本	交付哪一版、何时完成	初稿、修订稿或最终版

如果这些问题无法回答，先不要急着检查成品。输入不完整时，AI 可能会用看似合理的内容填补空白，而你最后检查的只是一个建立在假设上的结果。

用六道关卡替代一次性通读

可以把 AI 交付流程固定为“输入—目标—事实—格式—风险—责任”六道关卡。每道关卡只解决一类问题，避免在同一次阅读中同时检查所有内容。

第一关：输入是否完整

先对照原始需求和已提供资料，确认 AI 使用的输入没有缺项、错项或过期版本。

重点检查：

客户名称、产品名称、数字、日期和专有名词是否正确；
是否使用了最新版本的需求文件；
是否遗漏附件、表格、品牌规范或代码依赖；
关键背景是否只是你的推测，而不是客户明确提供的内容；
是否存在多个版本互相矛盾的资料。

可以把无法确认的内容标记为“待客户确认”，不要让 AI 自行补全。对于分析、报价、合同摘要和代码修改，输入版本尤其重要，因为一个小的版本差异就可能改变最终结论。

第二关：客户目标是否被落实

事实正确，不代表交付有效。接着检查每一部分内容是否服务于客户目标。

逐项问：

这段内容解决的是客户提出的问题，还是只是展示了 AI 能生成什么？
建议是否能被客户执行，还是停留在口号？
交付物是否适合实际使用场景？
是否为了追求内容完整，加入了与目标无关的部分？
客户验收时，能否指出哪些内容证明目标已经被满足？

例如，客户要的是“销售团队下周可以使用的咨询话术”，交付物就不能只是一篇关于销售沟通的长文，还应包含场景、话术、使用说明和必要的限制条件。

事实核验要分层处理

事实核验不应只检查明显错误，还要区分事实的风险等级。

高风险事实：必须找到依据

以下内容通常不能凭记忆或模型生成结果直接交付：

法律、税务、合同和合规结论；
医疗、金融、安全等可能影响决策的内容；
客户经营数据、市场数据和财务数字；
产品价格、功能、政策、资格条件和截止时间；
代码运行结果、接口参数和技术兼容性；
引用、统计数字、研究结论和案例效果。

检查时至少记录三件事：事实是什么、依据来自哪里、依据是否仍然适用。如果找不到可靠依据，就改写为待确认事项，或者明确说明这是推测而不是结论。

中风险事实：检查逻辑和上下文

例如行业惯例、流程建议、功能说明和用户画像。它们不一定需要逐句查证，但要确认没有把某个案例写成普遍规律，也没有把“可能有效”写成“必然有效”。

低风险内容：检查表达是否误导

观点、结构建议和创意文案虽然风险较低，也要检查是否暗示了未经证明的收益，或让读者误以为某项能力已经经过验证。

一个实用的标记方式是：

已核实：有明确资料或客户确认；
待核实：需要补充来源或让客户确认；
推测建议：基于经验提出，不是事实结论；
禁止外发：内部草稿、敏感信息或未获授权内容。

格式检查要独立进行

很多返工不是因为内容错，而是因为没有按要求交付。完成事实核验后，单独进行格式检查，不要把它混在内容阅读里。

文案与报告

检查：

字数、标题层级和段落结构；
是否包含客户要求的关键词或栏目；
语气是否符合品牌和受众；
表格、引用、编号和附件是否完整；
是否仍残留提示词、草稿说明或内部批注；
文件名、版本号和输出格式是否正确。

设计交付

检查：

尺寸、比例、颜色和字体是否符合要求；
图片、图标和字体是否有使用授权；
重要信息在不同屏幕或导出格式下是否清晰；
源文件、预览图和交付说明是否齐全；
是否出现 AI 生成图常见的文字变形、细节错误或不一致。

代码交付

检查：

是否能在约定环境中运行；
依赖、配置和启动步骤是否说明；
是否包含硬编码密钥、测试账号或内部地址；
异常处理、输入校验和权限控制是否存在；
修改范围是否超出客户授权；
是否完成基本的手工测试或自动化测试。

不要把“格式符合”理解为“看起来整齐”。格式的核心是客户能否直接使用、审阅和验收。

隐私保护要在提交给 AI 之前完成

隐私保护不能等到最终交付前才检查，因为敏感信息一旦进入不合适的工具或日志，事后删除未必能解决问题。

提交资料前先做三步：

识别：标出姓名、电话、邮箱、身份证件、账号、合同金额、客户名单、源代码、内部链接和未公开经营数据。
最小化：只保留完成任务所需的信息。例如将真实客户名替换为“客户A”，将订单号改为虚构编号。
确认权限：确认客户是否允许使用外部 AI 工具处理资料，并了解团队或工具的保存、共享和访问规则。

对于不需要真实身份的信息，优先使用脱敏样本。对于必须使用真实数据的任务，应先明确处理范围、保存期限、访问人员和删除方式。若无法确认，就不要直接上传。

最终交付前还要反向检查：是否把内部备注、隐藏批注、测试数据、访问令牌或未授权的客户信息一并发出。

设置“人工必须复核”的节点

一人公司不能把所有内容都交给 AI，也不需要逐字重做所有工作。更有效的方式是把人工注意力集中在高风险节点。

通常应由你亲自确认：

事实依据和关键数字；
面向客户的结论与承诺；
法律、财务、安全和隐私相关表述；
代码中的权限、密钥和数据处理逻辑；
最终版本是否符合客户目标；
是否有内容超出你的专业能力或授权范围。

AI 可以协助整理、改写、分类和发现遗漏，但最终交付责任仍由实际对客户负责的人承担。不要因为“模型生成的”或“客户自己提供的”就跳过判断。

一张可直接复制的交付前检查表

每次交付前，可以复制下面的清单，逐项填写状态和备注。

检查项	状态	备注
已确认客户目标与验收标准	□通过 □待确认
已使用正确版本的输入资料	□通过 □待确认
关键字段、名称、数字和日期无误	□通过 □待核验
高风险事实有明确依据	□通过 □待核验
未将推测写成确定结论	□通过 □需修改
交付格式、字数和结构符合要求	□通过 □需修改
客户能够直接使用或继续操作	□通过 □需修改
已删除提示词、草稿痕迹和内部备注	□通过 □需修改
敏感信息已脱敏或获得必要授权	□通过 □待确认
代码、设计或文件已完成基本可用性检查	□通过 □需测试
已标出客户仍需确认的事项	□通过 □需补充
我已确认最终版本并承担交付责任	□通过 □未确认