企业官网建设流程全解析

我先交代一个背景。前阵子有个朋友跟我抱怨，说他把项目里一个核心模块丢给 Cursor 重构，结果生成的代码表面上头头是道，一运行却直接打脸——连构造函数都调错了。他当时特别困惑：为什么 ChatGPT 时代都说 AI 写代码强，真到自己项目里就翻车？我跟他说，问题大概率不在 AI，在于它根本"没读懂"你的代码。很多人把 Cursor 当成一个更聪明的自动补全插件，装完就开始用，AI 给你的东西当然只能用"猜"的。

这篇文章我想认真聊聊，怎么从工程层面让 Cursor 真正理解一个项目的结构和意图，而不是靠运气补全。内容不是讲某个炫技技巧，是一套我自己在多个项目里跑通的、可复用的辅助编码实践，涵盖索引配置、规则文件、上下文管理、渐进式实现工作流、Agent 模式边界控制，还有一堆翻车现场复盘。适合刚开始用 Cursor 的人，也适合已经用了一段时间但总觉得"AI 不够懂我"的人。

1. 为什么 Cursor 会"假装懂"你的代码

1.1 先从一个翻车现场说起

有个朋友让我帮忙看一段 Cursor 生成的代码，需求很简单：把一个工具类里的parseConfig方法改成支持带默认值的解析。本来是个半小时的小改动，结果 Cursor 生成的代码不仅改了parseConfig，还顺手把同一个文件里另外三个方法的调用方式全改了，并且引用了一个并不存在的ConfigWrapper类。整个 diff 看起来逻辑完备，注释齐全，但项目里压根没有这个依赖。

这个案例特别典型，因为它精准地暴露了 AI 编码工具的底层困境：它生成的不是"基于理解的重构"，而是"基于概率的续写"。Cursor 看到你的项目里有几十个文件，它会尝试理解它们之间的关联，但这种理解非常浅——本质上是在海量代码里做模式匹配，找到"最像"的地方，然后延续这种模式。当项目结构不常见、命名不直观、或者某个模块的历史包袱很重时，AI 就会开始"自由发挥"。

1.2 AI"理解"代码的真相：索引、分块与近似匹配

弄明白 Cursor 是怎么"读"你的项目的，很多使用困惑都会迎刃而解。它首先会扫描你的代码库，建立一个索引，这个索引按文件、符号、调用关系等维度组织。当你提问时，它并不会把整个项目都读一遍，而是通过索引找出与你问题相关的若干片段，然后把这几段代码塞进上下文窗口，让大模型基于这些片段生成回答。

这个机制意味着三件事。第一，索引覆盖范围直接决定了 AI 回答能参考的候选集——有些文件如果没被索引，AI 想参考都参考不到。第二，相关性排序决定了 AI 优先参考哪些文件——如果你的代码里有同名函数，AI 可能选错那个。第三，上下文窗口大小决定了 AI 最终能"看到"多少代码，超过上限的部分会被截断，AI 并不会告诉你"我看漏了"，它只会自信地继续回答。这三个机制叠加，就是无数"看似正确、实则离谱"答案的来源。

1.3 "看似正确"比"明显错误"更危险

我自己的经验是，Cursor 给出的答案分三种：明显错、完全对、看似对。明显错的你一眼能看出来，完全对的直接用，最麻烦的是第三种——API 名字只差一个字母、参数顺序完全反了、异常处理逻辑放在错误的层级上。这种错误不会第一时间报错，而是等到某个边界条件被触发时才爆炸。

怎么应对？核心思路是建立"人机协作的反馈闭环"。不要让 AI 单方面输出，而是让它输出之后，你对它的理解进行校正。这也是整套实践方法论的起点：把 AI 当成一个阅读速度极快、但经常误读的结对程序员，而不是一个全知全能的代码生成器。有了这个定位，后续所有操作就都顺理成章了。

2. 项目记忆三件套：索引、忽略文件与规则文件的正确配置

2.1 索引配置：让 Cursor 知道看哪里、不看哪里

很多人的 Cursor 索引完全靠默认设置，这就埋下了第一颗雷。实际工程里，项目目录可能包含 node_modules、dist、build、vendor、third_party 这些第三方或生成代码。默认索引会把这些巨大的目录纳入扫描范围，不仅拖慢索引速度，更重要的是——AI 可以参考第三方库的代码模式来回答你自家业务代码的问题，风格和逻辑必然对不上。

正确的做法是给每个项目建一个.cursorignore文件，作用类似.gitignore。以下是我一个 Node.js 后端项目的配置示例：

node_modules/ dist/ build/ coverage/ .vscode/ .idea/ logs/ *.min.js *.map

配置完这个文件之后，最直观的感受是 Tab 补全的响应速度快了不少，因为 AI 不再需要从几万个第三方模块文件里做相关性匹配。更重要的是，回答质量明显更"聚焦"——它参考的几乎都是你自己的业务代码，风格一致性大幅提升。类似地，Python 项目要排除__pycache__、.venv、site-packages，Java 项目排除target/，这个需要按语言和框架灵活调整。

2.2 规则文件：给 AI 写一份"入职手册"

如果你只做一件事，那就把.cursorrules用起来。这个文件相当于给 AI 的"入职手册"——每次它回答你的问题时，都会先读一遍这个文件里的规则，然后按照规则约束自己的行为。这比你在每条 prompt 里反复强调"请保持代码风格一致"要可靠得多，因为规则是持久化的。不用每次重新说，AI 也更容易遵循系统级的约束。

要注意的是，.cursorrules是 Cursor 的官方机制，但把规则改个文件名放在项目根目录，用@手动引用，效果也类似。我的习惯是两者结合：项目级规范放在.cursorrules，通用团队规范放在共享文档里按需引用。下面是一份我常用的规则模板，你可以直接改改用：

你是一个资深软件工程师，在回答编程问题前必须遵循以下规则： 1. 不要臆造不存在的函数、类、模块；如果不确定项目里是否有某个 API，先搜索确认。 2. 代码风格遵循项目现有约定，保持与周围代码一致，不要引入全新的格式或模式。 3. 所有修改必须考虑现有的异常处理逻辑和边界条件，不得破坏原有行为。 4. 如果需求本身不清晰，先列出你的疑问，而不是猜测并直接生成代码。 5. 涉及多个文件改动时，先说明改动计划，等待确认后再逐文件修改。 6. 禁止修改与需求无关的代码。

别小看这份文件，它解决的是 AI 编码时最让人崩溃的三个问题：编造 API、风格漂移、擅自扩大修改范围。我把它引入团队后，AI 生成代码的"可用率"（指生成后不需要大幅重写的概率）从大概 30% 提升到了接近 70%，这个提升幅度远超换模型本身的效果。

2.3 项目说明文档：补上 AI 缺失的"业务脑"

规则文件解决的是行为规范问题，但很多项目还有一个更深层的问题——AI 不懂业务。一个微服务项目里，user表为什么有status字段？为什么order模块的金额计算要单独抽一个MoneyService？这些"为什么"通常不在代码里，而存在于 README、架构文档、甚至团队老人的脑子里。

我强烈建议在你的项目根目录维护一份AGENTS.md或者叫AI_CONTEXT.md的文档，专门写给 AI 看。内容可以很直白，包括：项目是干什么的、核心业务概念有哪些、关键技术决策及原因、目录结构说明、常见坑点。Cursor 的索引会读取这个文件，你在提问时提到相关概念，它能直接从这份文档里获得"背景知识"。

这份文档的写作不需要太正式，我自己一般控制在 200 到 500 行以内，按模块分节，每节三五句话。投入大概一两个小时，换来的是 AI 在整个项目生命周期内都带着"业务常识"工作，性价比非常高。AGENTS.md这个命名现在已经在很多团队里成了事实标准，因为各家 AI 编程工具都把它作为可以依据的项目意图描述。还有一个好处是它本身就在代码库里，新人入职也可以看，一举两得。

3. 上下文投喂：AI 回答质量的隐形天花板

3.1 为什么 AI 会"突然失忆"

我经常被问到的一个问题是：同一个对话里，前面聊得好好的，怎么聊到后面 AI 就开始胡说八道了？原因在于上下文窗口有限，而且 Cursor 对对话历史的处理策略是"保留最近 + 丢弃更早"。当你跟它连续交互了很多轮，早期提到的关键约束可能已经被截断，而 AI 不会主动告诉你"我忘了之前说过的需求"。

举个真实例子。有次我让 Cursor 帮我优化一个分页查询接口，最开始明确了排序规则、过滤条件、响应结构。聊了大概半小时，改了好几轮之后，它突然在生成的代码里去掉了分页参数校验，理由是"简化处理"。从它的视角看，它根本"不记得"之前提过校验要求了。

这个问题的解法不是去抱怨模型，而是建立"上下文快照"的习惯。

3.2 高杠杆操作：合理引用与主动粘贴

Coder 类工具的交互界面里，@引用是最有用的功能之一，但很多人并没有用好。不是在输入框里随便敲个@文件名就算完事，关键是要有选择地引用。我总结出一个"三层投喂"的结构：

• 第一层是架构文档或模块说明：让 AI 了解这段代码在整个项目里的位置和职责。可以@引用AGENTS.md或相关模块的设计文档，如果没有，就用自然语言给它补一段背景说明。
• 第二层是接口签名和关键数据结构：比如 DTO、实体类、函数签名，如果项目里有现成的类型定义文件，直接@引进来。
• 第三层是具体要改的代码片段：把目标函数或文件的相关部分粘贴在提问里，而不是笼统说"帮我改一下userService里的login方法"。

这三层都齐了，AI 的上下文就非常完整。这里有个小细节：不要只依赖@引用，有时手动粘贴关键代码段反而更可靠。因为@引用相当于告诉 AI"上下文里有这个文件，但 AI 仍然只根据它自己的判断来决定要看哪部分；如果你直接把关键代码段贴进对话，AI 会把它当作当前问题的核心输入优先处理。实测中，对于 100 行以内的关键函数，直接贴代码比@引用更稳。

3.3 一个会话只干一件事

很多人习惯一个对话窗口从头聊到尾——从项目初始化聊到代码重构聊到 bug 排查，最后还要让 AI 帮忙写提交信息。这样做的后果是上下文越来越脏，各种不相关的约束混在一起，AI 的回答质量会肉眼可见地下降。

我的规则很简单：一个会话只干一件事，比如"修复 A 模块的分页 bug"就是一个会话，"重构 B 服务的错误处理"是另一个会话。每次开新会话时，把关键背景用 5 到 10 句话重新说清楚，配合@引用和代码粘贴，成本很低，但收益非常大。这就像你给一个新同事交代任务，一次只安排一件事，他做好的概率远高于同时压三件事。

3.4 上下文不是越多越好

这里要特别强调一个反直觉的结论：上下文过多和过少一样有害。因为大模型会平均分配注意力，当上下文里塞满了无关代码，真正关键的约束会被"淹没"。我自己早期犯过的错误是，为了让 AI"充分理解"，把整个模块 1000 多行代码一次性贴进去，结果它生成的代码里出现了很多"幻觉参考"——把模块 A 的私有方法名用到了模块 B 里。

所以上下文投喂的原则是：讲清楚背景，给出接口，粘贴关键实现，而不是全文粘贴。让 AI 知道你希望它站在什么视角处理问题，然后给它看到足够展开工作的具体代码即可。剩下的让它自己去索引里翻。

4. "先评审再动手"：一套渐进式实现工作流

4.1 第一步：需求澄清模式，让 AI 先提问

我最早用 Cursor 的时候，习惯是"需求一句话 + 回车"。比如"帮我优化这个函数"，然后期待它直接给出最优解。后来发现，这种"一句话需求"通常会得到"泛泛的、看似合理但不适配具体场景"的输出。比如你说"优化"，它可以优化性能，也可以优化可读性，还能优化异常处理——不同的优化方向，写出来的代码截然不同。

现在我要求自己至少在需求描述里包含三要素：目标（这段代码要达成什么样的行为）、约束（不能改变哪些外部行为、不能引入哪些新依赖）、验收标准（怎么看改完算成功）。如果连我自己都说不清这三要素，那就意味着需求还不明确，这种情况下我会让 AI 先列出疑问，而不是直接动手写代码。

这是我在重构一个支付回调模块时用的需求描述模板，你可以参考：

背景：目前支付回调处理逻辑散落在 controller 层，导致无法复用且测试困难。 目标：将回调验签、业务处理、异常记录抽成一个独立的 service，保持接口行为完全不变。 约束： - 不能改变现有数据库表结构； - 不能引入新的消息队列依赖； - 回调响应的格式（XML/JSON切换逻辑）保持不变。 验收标准： - 现有接口测试全部通过； - 新增 service 的单元测试覆盖验签失败、业务异常、未知异常三个分支。

注意，这段描述里的每条信息都直接决定了后续生成的代码长什么样。你给 AI 的约束越具体，它"瞎猜"的空间就越小。

4.2 第二步：方案评审，让 AI 给出多方案与取舍

在需求澄清完、正式写代码之前，我还会多做一个步骤：让 AI 先给方案，不要直接给代码。比如我可能会追问一句"针对这个目标，你有哪几种实现思路？各自的优缺点和风险是什么？"然后让它用表格或分点列出两到三个方案。

这个步骤的价值在于，它把 AI 从"代码生成器"变成了"方案讨论者"，等于强迫它先做全局思考再落笔。很多错误的根因其实就是跳过了方案设计直接进入细节实现，如果 AI 一开始就走错了方向，那它后续生成的每一个函数都是在这个错误地基上盖楼。

拿到方案后，我会做筛选、补充或者否决，理由包括"方案 A 引入了新依赖，我们项目限定不能用""方案 B 改动量太大，要想办法缩小范围"。然后把这个讨论过程也在对话里说清楚，再让 AI 进入编码。经过这一步之后，AI 生成的代码和需求的匹配度会大幅提升，因为它不仅知道"要做什么"，还知道"为什么在这个项目里选这个方案"。

4.3 第三步：增量编码，一次只改一个小单元

现在进入编码环节。这里我有一条硬性纪律：一次只让 AI 改一个函数、一个文件、一个模块，改完立即检查，然后再进下一个。千万不要让 AI"一口气把所有相关文件都改完"，因为一旦改动面铺得太大，出了问题你根本不知道是哪一步引入的。

在提示词里，我会明确指定修改范围，比如"只修改user_service.py中的login方法，其他方法保持不动"。如果 AI 自动给我改了其他方法（这种情况很常见），我会直接批评它并让它还原，必要时回滚到修改前的版本。这一条跟.cursorrules里的第 6 条规则是一致的，双重保障。

每完成一步，我会让 AI 简单总结它改了什么、为什么这么改。这样万一后续发现问题，我能很快定位到具体那一步。这种增量模式虽然看起来"慢"，但综合效率远高于"一次生成一坨再花大半天 debug"。

4.4 第四步：代码审查反向提问，让 AI 自证清白

改完之后，我还会做一步很多人忽略的操作：让 AI 解释它自己的代码。不是让它复述代码（那毫无意义），而是让它回答几个"找茬"问题，比如"这段代码在并发场景下是否存在竞态条件？""这里的异常处理覆盖了哪些路径？漏掉了什么？""如果传入参数是空值会怎么样？"

这一步的机制在于：当 AI 被要求审査自己的代码时，它其实是在生成一个全新的推理过程，这个过程中更容易暴露之前的逻辑漏洞。我遇到过很多次这样的情况：让它解释某个边界情况，它解释着解释着就"发现"了自己代码里有问题，然后主动承认"这里处理得不对"。这比你去人肉 review 每一行代码要高效得多。

4.5 完整工作流落地后的实际效果

为了让你更直观地感受这套工作流的价值，我把对比结果列成一个表。同样是"给支付回调模块加一个重试机制"的需求，用传统方式和渐进式工作流的效果差异非常明显：

这个表里的数据来自我自己的项目统计，不同项目会有波动，但趋势是一致的。核心原因很好理解：AI 编码出错的大头从来不是"写不出代码"，而是"理解错了需求"或者"缺少约束就自由发挥"。这套工作流本质上是在用流程约束把这两大问题的概率压下去。

5. Agent 模式不是甩手掌柜：边界、验收与回滚

5.1 Agent 模式能做什么：一次看清工具能力边界

Cursor 的 Agent 模式（比如 Composer，以及最近更新的更激进的自动执行模式）确实很强，它能自己读取文件、修改多个文件、运行命令、执行测试，像一个真正的初级工程师在工作。很多人第一次用的时候会非常震撼——你说"帮我实现一个用户注册接口"，它哗啦啦把 controller、service、model、migration 全都建好了，还自动跑了一遍测试。

但正因为强，所以更容易翻车。我的经验是，Agent 模式适合两类任务：一类是机械重复的样板代码生成（比如按现有模式新增一个 CRUD 接口），另一类是跨文件的简单一致性修改（比如统一把某个旧的工具函数调用替换成新函数）。它不适合的任务是：需求本身很模糊、涉及复杂的业务分支、或者几个文件之间有微妙的耦合关系。

5.2 给 Agent 设置明确的"完成定义"

让 Agent 模式跑起来之前，我强烈建议给它一个明确的"完成定义"(Definition of Done)。否则它会按自己的标准"觉得做完了"就停下来。我常用的模板是：

你的任务完成后，需要满足以下标准才能结束： 1. 所有新增和修改的文件都已列出，并说明每个文件的改动目的。 2. 相关单元测试全部通过，如果有失败的需要先修复。 3. 编译/构建流程无报错。 4. 不改变与需求无关的现有行为。 5. 如果过程中遇到需要我决策的问题，停下来问我，不要自行假设。

有了这个明确的结束契约，Agent 的行为会收敛得多。它不再一股脑地只把代码生成完就停手，而是会自己检查测试、确认构建、补齐遗漏。当然，即便有了 DoD，我仍然不建议在 Agent 模式下让它自主处理超过三四个文件的大任务。一旦改动面扩大，它自己的"任务追踪能力"会显著下降，最后可能漏改文件或者改过头。

5.3 "AI 改崩了"之后的回滚策略

"AI 把代码改坏了怎么办"这个问题，我几乎每隔几天就会遇到。最关键的一条原则是：改动前确保代码库处于干净状态，并且有可回滚的检查点。如果在 git 工作区不干净的情况下让 Agent 跑起来，它一旦改动错乱，你连"哪些是它改的、哪些是我自己改的"都分不清，回滚会变成一场灾难。

给几个实战建议：让代码动工前先git status确认工作区干净，或者至少把当前未提交的改动单独 stash 备份。如果 Agent 的任务涉及多个文件，在它动手前就把基线 commit 打好。这样一旦它改崩了，你可以直接git checkout -- <file>恢复单个文件，或者git revert整体回退。还有一个习惯也值得养成：在让 Agent 执行大改动前，先在对话里让它输出一份改动计划，这份计划天然就是一份心理上的"回滚契约"——你知道它打算动哪些文件，出问题时就知道去哪些位置查。

6. 常见翻车现场复盘：从症状定位根因

6.1 症状一：答非所问，AI 改了一个不相关的函数

这类问题出现时，先别急着骂 AI。先想想：你给它的上下文里，是否混入了多个相似函数？或者代码库里是否存在同名函数？在@引用文件时，AI 有时会把"名字相似"的两个函数搞混。我遇到过一次，因为项目里既有formatUserData又有formatUserDataV2，AI 在回答时张冠李戴，把 V2 的代码生成进了旧函数里。

排查思路是：回看它引用了哪些上下文，主动在提问中纠正："我说的formatUserDataV2是 200 行那个，不是 50 行那个。"如果这种情况频繁发生，建议检查索引是否过期——某些场景下 Cursor 的索引没及时更新，它看到的代码和磁盘上的真实代码不一致。重启 Cursor 或在设置里触发一次 reindex，通常能解决。

6.2 症状二：编造不存在的 API 和方法

这是大家吐槽最多的一个现象。AI 生成了configManager.overrideConfig()，一查代码库，根本没有这个方法。原因是模型在训练时见过太多类似的代码，它顺着"最可能的续写"走了，而不是顺着"项目里真实存在的 API"走。

解决方案有三个层面：第一层，在.cursorrules里加规则"不要臆造不存在的 API，如果不确定就直说"，这能大幅降低发生率。第二层，在提问时主动告诉它"这个模块的 API 列表如下，你只能使用这些方法"，然后给它一份真实的接口清单。第三层，审查阶段让 AI 自己解释它使用的方法是在哪里定义的，这一步能逼着 AI 主动检查自己的输出。三层叠下来，编造 API 的情况基本能压到极低。

6.3 症状三：循环空转，改了又改但问题的本质没变

有时候 AI 会陷入一种"勤快的错误循环"：你说修复一个问题，它给你改了三轮，每轮都在改表面症状，但根本原因纹丝不动。比如你让它处理内存泄漏，它反复优化循环里的临时变量，却完全没发现是某个全局大对象没有被释放。

遇到这种情况，最有效的操作不是让它"继续修"，而是让它停下来，重新做诊断。我会把它之前的所有修改丢弃，回到原始代码，然后换一种问法："不要急着给方案，先帮我定位可能引发内存泄漏的三个位置，并说明理由。"通过这种方式把 AI 从"代码生成模式"切换到"代码诊断模式"，往往第二三轮就能从不同角度给出有价值的线索。

6.4 症状四：风格漂移，代码和项目风格明显不一致

AI 生成的一百行代码里，变量命名是驼峰，项目的其他地方全是下划线；新代码用了一个完全没必要的设计模式，可项目里到处都是简单的过程化写法。这种情况非常普遍，本质是AI 缺乏"项目风格记忆"。

预防方案其实前面已经提到过：一是在.cursorrules里明确风格要求，二是引用项目内现有的同类文件让 AI 模仿。事后补救的话，直接告诉它："参考src/utils/legacyHelper.js这个文件的命名和代码组织方式，把刚才生成的模块重写一遍。"这个招数通常很管用，因为 AI 非常擅长"照葫芦画瓢"。

6.5 从症状到根因：一份排查链路图

把上面这些经验压缩成一句排查思路的话：

先看索引是否覆盖了相关文件，再看本轮上下文是否选对了引用的文件，再看规则文件是否约束了行为边界，最后看需求描述本身是否足够具体。

这个顺序是我踩过很多次坑之后总结出来的，每一步都对应着一类常见根因。排查时按这个顺序走，大多数问题都能在几分钟内定位，而不是陷入"让 AI 改到对为止"的无底洞。

7. 团队落地时的三个提醒：隐私、规范与使用边界

7.1 代码会被发到哪去：隐私合规先想清楚

先聊一个很多团队负责人忽略的问题。Cursor 这类 AI 编程工具在你提问时，会把相关代码片段发送到它的服务器，用来生成回答。对于个人开发者，这可能只是隐私偏好问题；但对于公司项目，尤其是涉及用户数据、核心算法、商业机密的代码，这可能直接违反合规要求。

我之前见过一个团队，把包含内部加密算法的模块喂给 AI 做优化，后来才意识到这个行为的数据合规风险非常大。所以在正式把 Cursor 引入团队之前，最好先跟法务或安全同事确认：哪些代码可以交给 AI，哪些绝对不行。如果确实有敏感代码需要处理，稳妥的做法是把敏感部分抽象成接口描述再喂给它，而不是贴原始实现。关于"提示词会不会被拿去训练模型"这类问题，各家的条款变化很快，建议以官方文档为准，定期复查。

7.2 把经验沉淀成团队资产

团队里每个人使用 Cursor 的水平参差不齐，有人能把 AI 调到"指哪打哪"，有人只会让它写点辅助函数。为了让整个团队受益，我建议把个人的实践沉淀成团队模板：把.cursorrules和AGENTS.md收进代码库，所有人都能共享；把常用的需求描述模板、审查提问模板写成团队文档；在代码评审时，不仅评审人的代码，也评审 AI 参与的部分——AI 生成的代码同样需要 review。

这套沉淀一旦跑起来，新成员上手 Cursor 的速度会非常快。因为工具本身的门槛不高，真正稀缺的是"怎么用才不会翻车"的经验。这些经验如果能以文件、模板、规则的形式固化下来，它会像代码库里的库函数一样，产生复利效应。

7.3 认清边界：什么时候不该用 Cursor

最后想提醒一点，不是所有代码都适合让 AI 来写。至少有几类场景我建议你亲自动手：牵涉核心业务逻辑、故障影响面特别大的模块；需要极强的领域建模能力、贸然引入一段"看起来通用"的代码反而破坏设计的一致性；以及你自己正在学习某项新技术、希望借此深入理解它的时候。

我在实际项目中的一个体会是：Cursor 最擅长的是把你脑子里的清晰想法快速变成代码，而不是替你想清楚"产品到底需要什么"。那些真正复杂的设计决策、领域划分、模块边界，还是得靠人脑。工具的本质是放大器，它放大的是你的思路，而不是替代你的思考。这一点想明白了，Cursor 就是得力的帮手；想不明白，它就会变成一个"高水平实习生"——给他模糊的指令，他会还你一堆需要返工的东西。