网站建设公司用 Claude Code 把提案书和需求访谈表的时间砍掉一半

周五傍晚，下周一就要去竞标。需求只是零散地散落在群里聊天记录中。销售做的访谈笔记躺在三个文档里，而且还是分点列到一半就断了。

我就是从这种状态开始，一个人加班拼出一份提案书。封面、问题梳理、网站结构图草案、排期、报价的前提条件。深夜两点，好不容易做完回头一看——访谈时明明听到客户说”招聘是本季度的头号优先级”，可这句话在提案书里一个字都没体现。听到了，却没接住。

只要你是网站建设公司的项目负责人，对这种”听到了却漏掉”的感觉一定不陌生。提案书和需求访谈表，做的数量不少，可很多人每次都是从零重新写。把这一块交给生成式 AI，就能把省下的时间挪到”打磨提案的内容”上。今天我就把具体做法写清楚，附带可以直接复制的提示词和验证脚本。

本文要点

提案书和需求访谈表是”格式固定的文档”，所以和 Claude Code 这类生成式 AI 很合拍。初稿的七成可以交出去。
交出去的是”整理散乱信息”和”往模板里灌初稿”。提案的策略、报价金额的最终判断，必须由人来做。这两块混在一起就会出事。
把访谈笔记丢进去生成提案书骨架，在我手上单件从 90 分钟缩到了 40 分钟左右。
客户公司名、个人信息不被用于训练的设置，以及信息怎么递进去，都需要注意。后面我整理成了检查清单。
文末附上可直接复制的提示词模板、需求访谈表的 Markdown 模板，以及自动检查提案书有没有漏项的验证脚本。

读者画像：哪类网站建设公司的项目负责人最受用

我设想的是这样一类人。一家 5 到 30 人规模的建设公司，项目负责人同时还兼着销售。每月要出 2 到 5 份提案，竞标和比价的场合也多。设计师和工程师另有其人，但访谈和提案书制作全压在项目负责人一个人身上。

这个位置上的烦恼大都相通。想用提案的内容一决胜负，时间却被整理文档的活儿吸走。访谈聊得很热烈，可笔记零散，事后根本还原不出来。模板是有，但每个项目都略有不同，结果还是要手动改。

生成式 AI 真正管用的，正是这个”整理”环节。并不是把提案的构思本身整个甩给 AI。

网站建设公司的工作流，时间到底化在哪里

把出提案前的流程一字排开，时间的去向就看清楚了。

接收咨询、做首次回复
访谈（面对面或线上），做笔记
整理笔记，把需求归拢清楚
确定网站结构图、线框图的方向
排出排期和概算报价
落成提案书（幻灯片或文档）
内部评审后提交

其中第 3 步和第 6 步是最大的瓶颈。访谈笔记原封不动用不了，整理要花时间。提案书每次结构都差不多，可每个项目的信息要手动灌进去，返工多。

按我的感觉，单个项目光做提案书就要 90 到 120 分钟。一个月三件，光这一项就有 5 到 6 个小时耗在”整理文档”上。

常见的返工和烦心事

我把实际翻过的车老实排出来。

访谈漏问。忘了问预算大致范围和期望上线日期，提案书交出去后被一句”超预算了”打回重做。
笔记理解偏差。“想做手机适配”，到底是响应式适配还是专门的 App，含糊不清就提了案，报价差了两倍。
模板复用出错。上一个项目的公司名还留在封面上，差点就提交了。这真的是冒冷汗。
提案书漏项。忘了写运维费用，接单后变成”我没听说过月费”的纠纷。

这些大半，只要”每次把固定项目一个不漏地填满”就能避免。靠人每次手动来，就会漏。所以让机器来把关。

引入前后，到底变了什么

把前后对比列成表。

项目	引入前	引入后
访谈笔记整理	手动花 30 分钟誊清	AI 5 分钟结构化，人来确认
提案书骨架制作	从白纸 60 分钟	灌进模板 20 分钟
漏问检查	靠记忆	用验证脚本自动检查
封面公司名出错	偶尔发生	模板变量化后几乎归零
单件合计	90 到 120 分钟	40 到 60 分钟

想策略的时间不会减少。减少的只是”整理和确认”的时间。这恰恰是我最想自动化的部分，所以对我来说正中下怀。

用例 1：从访谈笔记生成提案书骨架

最管用的就是这个。把访谈刚结束的原始笔记丢进去，让它按提案书的章节顺序起一份初稿。

用 Claude Code 的话，把访谈笔记的文本文件放进项目里，就能直接让它读。复制粘贴也能跑，但让它直接读文件，转录出错会更少。

下面这段提示词，请当作模板来用。

你是网站建设公司项目负责人的助手。
请阅读附带的访谈笔记，按以下章节结构写出提案书初稿。

# 章节结构
1. 客户当前面临的问题（在笔记能读出的范围内。推测要标明"推测"）
2. 本项目的目标
3. 设想的网站结构图（仅主要页面）
4. 推进方式与大致排期
5. 概算的前提条件（不写金额，只把报价所需的前提分点列出）

# 必须遵守
- 笔记里没写的不要编造。缺失的内容作为"待确认"汇总在末尾
- 专业术语要以客户阅读为前提，换成通俗的说法
- 不要下太死的结论，作为提案的草稿来写

关键是用”笔记里没有的不许编造”来约束它。AI 喜欢把空白填上，放任不管它就会擅自造出根本不存在的需求。把缺口赶进”待确认”，漏问的地方就直接可视化了。

用例 2：让需求访谈表本身按项目优化

需求访谈表很容易拿一份固定问卷反复用，但行业和项目规模不同，该问的东西就不一样。招聘网站和电商网站，问的顺序和内容都不同。

所以，把项目概况递进去，让它重组问卷。

请为下面这个项目，做一份首次访谈的问题清单。

# 项目概况
- 行业: 牙科诊所
- 目的: 增加新患者预约
- 规模: 10 页左右的企业站 + 预约引导

# 输出格式
- 分成"必问的问题"和"有条件就问的问题"
- 每个问题附一句话，说明为什么要问（影响提案或报价的哪一环）
- 预算、期望上线日期、是否有现有网站、照片素材是否备齐，必须包含

让它附上”为什么要问”，访谈当天项目负责人本人的理解也会更深。用来培训新手项目负责人也很顶用。

用例 3：多份笔记的整合，以及提案书的体例检查

当销售、项目负责人、客户来信，信息散落在好几处时，让它整合成一页。下面这份检查清单，请用在提案书的最终确认上。

封面的公司名、项目名是不是这次的
写没写预算大致范围，或报价前提
期望上线日期和排期有没有矛盾
运维费用的处理有没有写明
网站结构图和报价的页数对不对得上
访谈中提出的最高优先需求有没有体现
“待确认”项目有没有还没解决就提交

这份检查靠人眼也能做，但后面我会给出用机器检查的方法。眼睛看一定会漏。

交给 AI 的范围，和人必须判断的范围

这条线一含糊就会出事。我把界限列成表。

工作	交给 AI	人来判断
笔记整理、结构化	◯	最终确认
按章节结构写初稿	◯	语境修正
问卷重组	◯	当天深挖
提案策略、差异化方向	△仅草稿	◎最终决定
报价金额定稿	×	◎
是否提交给客户	×	◎

金额和提交的最终判断，绝对由人来做。把 AI 给的概算原样丢给客户，等于把报价整个甩给新人，让他闷不吭声地交出去。划清”到草稿为止才是职责范围”，用起来就踏实了。

自动检查提案书有没有漏项的验证脚本

人眼检查，累的时候就会漏。所以这里放一个小脚本，读取提案书的 Markdown，机器化地确认”必填项目在不在”。只要装了 Node.js 就能跑。

前提是提案书用 Markdown 写。就算是幻灯片，只要导出成文本走一遍也能用。

import { readFile } from "node:fs/promises";

// 提案书里必须包含的项目，以及标示它的关键词
const checks = [
  { label: "问题梳理", keywords: ["问题", "现状", "痛点"] },
  { label: "目标", keywords: ["目标", "目的", "KGI", "KPI"] },
  { label: "网站结构图", keywords: ["网站结构图", "页面结构", "站点地图"] },
  { label: "排期", keywords: ["排期", "工期", "上线"] },
  { label: "报价前提", keywords: ["前提", "概算", "报价"] },
  { label: "运维", keywords: ["运维", "维护", "月费"] },
];

const file = process.argv[2] || "proposal.md";
const text = await readFile(file, "utf8");

let missing = 0;
for (const c of checks) {
  const hit = c.keywords.some((k) => text.includes(k));
  if (hit) {
    console.log(`OK  ${c.label}`);
  } else {
    console.log(`NG  ${c.label}  ← 找不到这一项`);
    missing++;
  }
}

// 简易检查上一个项目的公司名有没有残留
const ghost = ["示例有限公司", "某某公司", "上个项目"];
for (const g of ghost) {
  if (text.includes(g)) {
    console.log(`NG  占位符「${g}」还留着`);
    missing++;
  }
}

if (missing === 0) {
  console.log("\n所有项目通过。可以进入提交前的最终人工核对。");
} else {
  console.log(`\n有 ${missing} 处漏项。改完再提交。`);
  process.exitCode = 1;
}

用法就这一行。

node check-proposal.mjs proposal.md

就这几十行，却能拦住”忘写运维费用”和”封面残留旧公司名”这两个我每次都翻的车。关键词请按自家提案书的措辞去补。它不是完美的判定，作为放在人眼前的”最后一道守门人”，刚刚好。

顺带一提，还能让 Claude Code 跑这个脚本，看完结果再把提案书改好，整条链路都交出去。做法的基础我整理在Claude Code 入门指南里。

安全与个人信息的注意事项

处理的是客户信息，这里不能马虎。最起码这几条请守住。

关掉训练使用。工作场景用的话，要选输入内容不被用于训练的方案和设置。在 Anthropic 的使用条款与隐私政策里先确认清楚处理方式。
递进去的信息要最少。做提案骨架，没必要把对方负责人的私人手机号、报价成本都递进去。只递必要的范围。
先匿名化再递。把公司名、人名换成”A 公司""负责人 X”再处理，最后由人改回真名。光这一步，万一泄露时损失就会小很多。
生成物必须由人确认。AI 写的东西不要原样丢给客户。里面可能混进错误，或说过头的表述。

如果和客户的合同里有”限制转委托或使用外部工具”的条款，过生成式 AI 之前务必先确认。跳过这一步，就不是效率问题，而是信任问题了。

简单的 ROI 估算

粗略算一笔。假设单份提案书从 90 分钟缩到 50 分钟，省下 40 分钟。一个月三件就是 2 小时。把项目负责人的时薪假设为 200 元，那就是每月省出 400 元的时间。

比金额更大的，是这 2 小时可以挪去”打磨提案内容""调研竞品”。把原来用在整理文档上的时间，转到能影响接单率的活儿上。这一点比数字更管用。

把提示词的精度提上去，还能再缩。写法的诀窍，可以参考让提案通过的高级提示词技巧和加快工作的小技巧集。怎么把团队的写法统一沉淀下来，也可以看CLAUDE.md 最佳实践。

常见问题

Q. AI 做的提案书能原样交给客户吗？ 不要交。那是草稿。策略是否站得住、金额、表述，都得由人改。要交，也得等到人确认过、能担起责任之后。

Q. 访谈笔记是手写的、很乱，能用吗？ 把照片转成文字再递进去就能用。不过会混进误读，专有名词和数字（预算、日期）请由人复核。

Q. 能套到我们自家的模板上吗？ 能。把自家的章节结构贴进提示词，它就会按那个格式写。做好一次的提示词，建议在团队里共享反复用。

Q. 问设计的事有用吗？ 能当方向上的草稿，但设计的最终判断请交给设计师。AI 擅长”用文字整理”，可视觉好坏的最终判断是人的领域。

Q. 没有专业知识也能用起来吗？ 能。只要贴提示词、确认结果，不需要写代码。团队铺开的思路，我整理在非工程师如何用 Claude Code里。

我实际试下来的结果

我用手头过去 5 份访谈笔记，把这套流程跑了一遍。我确认了三件事。

第一件是时间。骨架制作平均从 60 分钟缩到 20 分钟左右。算到完成的合计，多数件也收在了 90 分钟变 40 到 50 分钟。与其说快得吓人，不如说”每次都卡住的那道整理台阶”消失了。

第二件是漏问。“笔记里没有的不许编造”这条约束效果很大，过去笔记里漏了预算或上线日期的项目，都老老实实地排进了”待确认”。比靠记忆的时候，确实接得住了。

第三件是验证脚本。我故意拿一份删掉运维费用的提案书，和一份留着旧公司名的提案书走了一遍，两份都以 NG 被拦下。作为提交前的最后一道关，足够用了。

结论是：提案的构思照旧由人来做。但在这之前的”整理散乱信息""灌进模板""确认漏项”，已经不用再手动做了。把省下的时间挪到提案内容上——这种用法，我觉得对网站建设公司的项目负责人最受用。

想把它当成机制在团队里跑起来、或当成培训引入的话，请从培训与咨询入口联系我们。