王工是小区里口碑最好的装修监理，老李则是手艺最巧的敲钉工匠。老李的绝活是“指哪敲哪”——你说敲这颗钉子，他绝不多动一锤。可装修一套房子，真正累人的从来不是敲钉子，而是想清楚哪些墙能拆、电路怎么走、木工和油漆工怎么衔接。老李帮不上忙，王工却可以：你只要说一句“想把客厅改成北欧风”，他就能把整层楼的图纸摊开，告诉你哪堵墙要拆、哪个插座要移位、灯具窗帘怎么换，等你点了头，施工队才进场。 这个故事里，老李是传统 AI 编程助手，王工就是 Cursor 的 Composer。它不再满足于“补全你正在敲的那一行代码”，而是把你的自然语言要求，变成一份跨多个文件的整体变更方案：先规划，再动手，全程可审阅。它把 AI 编程从“敲钉子”推进到了“搞装修”。

岗位关联

对 AI 从业者而言，理解 Composer 能帮你从“会调 AI 补全”进阶到“会驱动 AI 完成整块工程变更”——这是 AI 编程助手时代最值钱的工程能力之一。

目录
  1. 可视化演示
  2. 功能定位：从敲钉子到搞装修
  3. 工作流程：一次装修的四步走
  4. 核心技术：王工的脑内活动
  5. 模式对比：四支施工队
  6. 典型场景：什么时候该叫监理
  7. 实践要点：业主配合守则
  8. 局限与未来：装修队的明天
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示Cursor Composer三大维度：多文件编辑（一条NL指令CMD同时修改DEF定义+CALL调用+TYP类型+TST测试4文件，人在环路HITL审查）、指令解析（NL→INT意图→DEP依赖图→PLN变更计划→RVW审查五阶段，12变更4文件85%通过）、依赖追踪（符号依赖图FN→4调用方→TS类型+SP测试，7节点8边4引用6变更自动同步）,三模式切换理解AI多文件编程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+C1+'

功能定位：从敲钉子到搞装修

老李的工位只有一把锤子。你让他换一颗门把手，他就只换门把手——门框的螺丝松了、门锁的位置偏了，他全看不见，因为他的世界聚焦在你手指的那个点上。王工则不同，他进门前先要整层楼的图纸，水电、木工、油漆、通风在他脑子里是一张互相关联的大网。一句“北欧风”，他能给出墙面、灯光、家具、窗帘的整套方案。

在 Cursor 里，老李对应的是 Tab 补全——你敲到一半，它帮你补完当前行；王工对应的是 Composer——你描述一个目标，它自己决定“要改哪些文件、各改什么”。从模型视角看，这是完全不同的生成问题。Tab 补全的条件是“光标左侧的若干文本”，输出是“接下来的几个文本单元”；Composer 的条件是“整个代码库 D 加上用户指令 C”，输出是一串编辑动作 Δ。数学上可以写成：

老李的世界只有一锤子的距离，王工的世界建在整层楼的图纸之上。Composer 之所以能成为“整体变更方案”的提供者，正是因为它把生成的每一步都放在全局上下文里做决策——这是它与 Tab 补全的分水岭。

P(Δ∣C,D)=∏i=1kP(δi∣C,D,Δ1:i−1)\displaystyle P(\Delta \mid C, D) = \prod_{i=1}^{k} P(\delta_i \mid C, D, \Delta_{1:i-1})
这个公式想表达：Composer 不是一次性“猜”出所有改动，而是一步一步生成，且每一步都回头参考前面已经做出的修改——像施工队每推进一个工序，都要以之前完成的部分为前提。
  1. 整体概率 P(Δ|C,D)给定用户指令 C 和整个代码库 D 之后，生成完整编辑序列 Δ 的概率。
    Δ=(δ1,δ2,…,δk)\Delta = (\delta_1, \delta_2, \ldots, \delta_k)
  2. 编辑动作 δᵢ一次最小的文件改动，比如“在 login.py 第 40 行加一个参数校验”。
    δi∈{insert,delete,modify}\delta_i \in \{ \text{insert}, \text{delete}, \text{modify} \}
  3. 连乘符号 ∏k 次改动的概率相乘，得到整份“施工图纸”的置信度。
    ∏i=1kP(δi∣…)\prod_{i=1}^{k} P(\delta_i \mid \ldots)
  4. 条件参数 Δ₁i₋₁：生成第 i 步时，之前 i−1 步改动全部作为已知背景。
    Δ1:i−1=(δ1,…,δi−1)\Delta_{1:i-1} = (\delta_1, \ldots, \delta_{i-1})

工作流程：一次装修的四步走

王工接活的规矩从来不变：测房、画图、业主确认、施工。第一步，他拿卷尺把每个房间量一遍，问清你的需求；第二步，出图纸，标出每面墙的处理方式；第三步，你不点头他不进场；第四步，施工并随时汇报进度。这套流程确保了每个环节都有据可查、随时可控。

Composer 完整复刻了这套流程。①描述需求：在 Composer 对话框里输入自然语言；②生成方案：它列出将改动的文件清单与每处修改的说明；③审阅变更：逐条查看 diff（文件改动对比预览），确认是否符合预期；④应用修改：确认后落盘到真实文件。落盘后还可以通过版本控制随时回滚——相当于装修出了问题还能恢复原样。

有人觉得“先审阅再动手”绕远路，但从工程成本看，恰恰相反。改一个文件要重新打开、定位、编写、验证；改错了还要返工，而返工的成本往往数倍于一次编辑。用公式表达：

请王工装修的人都明白一个道理：图纸阶段多花半天，往往能省下返工的一个月。Composer 的四步流程正是这个朴素经济学在编程世界的重演——先花小成本确认方向，再投入大成本执行。

Ctotal=Cplan+∑i=1nCedit(i)+Crework⋅perror\displaystyle C_{\text{total}} = C_{\text{plan}} + \sum_{i=1}^{n} C_{\text{edit}}^{(i)} + C_{\text{rework}} \cdot p_{\text{error}}
公式说明：返工成本往往是编辑成本的数倍甚至数十倍，所以提前花一点“规划成本”压低出错概率，总账反而更划算。这也是 Composer 坚持“方案先行”的原因。
  1. 总成本 C_total一次跨文件变更的全部代价，含人力与时间。
    Ctotal=Cplan+∑i=1nCedit(i)+Crework⋅perrorC_{\text{total}} = C_{\text{plan}} + \sum_{i=1}^{n} C_{\text{edit}}^{(i)} + C_{\text{rework}} \cdot p_{\text{error}}
  2. 先期规划 C_plan花在描述需求、审阅方案上的成本，是主动付出的“图纸费”。
    Cplan=tdescribe+treviewC_{\text{plan}} = t_{\text{describe}} + t_{\text{review}}
  3. 累加符号 Σn 个文件逐个修改的施工成本加总，文件越多这部分越大。
    ∑i=1nCedit(i)=Cedit(1)+⋯+Cedit(n)\sum_{i=1}^{n} C_{\text{edit}}^{(i)} = C_{\text{edit}}^{(1)} + \cdots + C_{\text{edit}}^{(n)}
  4. 返工期望项返工一次的成本乘以它发生的概率，是藏在总账里的隐形炸弹。
    Crework⋅perrorC_{\text{rework}} \cdot p_{\text{error}}

核心技术：王工的脑内活动

王工凭什么进门前就能说出“要拆这堵墙”？因为他的脑子里装着三样东西：同户型的所有图纸库（代码索引）、结构工程师的承重墙知识（依赖分析）、以及“先看主卧再看厨房”的取舍策略（上下文裁剪）。没有这三样，他接不了跨房间的活。

Composer 面对一个代码库时，第一步也不是生成，而是“找”。代码库可能有上千个文件，而模型的上下文窗口（一次能读入的文本量）装不下全部，它必须筛选出与本次任务最相关的文件。筛选依据可以抽象成一个打分函数，给每个候选文件算一个“该不该看它”的分值：

选出相关文件后，Composer 还会分析文件间的依赖关系，确保改动顺序合理——就像王工知道“拆墙前必须先断电”。最后把所有修改打包成补丁（patch），交给用户审阅。脑内活动结束，图纸出炉。

score(f)=α⋅cos⁡(e⃗f,e⃗q)+β⋅deg(f)−γ⋅log⁡(size(f))\displaystyle \text{score}(f) = \alpha \cdot \cos\left(\vec{e}_{f}, \vec{e}_{q}\right) + \beta \cdot \text{deg}(f) - \gamma \cdot \log\left(\text{size}(f)\right)
每一类候选文件都会按“和需求有多像、有多少文件依赖它、体积会不会撑爆上下文”三个维度打分，分数高的才能进“施工图纸”。
  1. 打分函数 score(f)给文件 f 计算与当前任务的关联程度，分数高者优先被读取。
    f∈Fcandidatef \in \mathcal{F}_{\text{candidate}}
  2. 语义相似度 cos把文件和指令都编码成向量，计算夹角的余弦值，衡量“意思接近”。
    cos⁡(e⃗f,e⃗q)=e⃗f⋅e⃗q∥e⃗f∥∥e⃗q∥\cos(\vec{e}_f, \vec{e}_q) = \frac{\vec{e}_f \cdot \vec{e}_q}{\lVert \vec{e}_f \rVert \lVert \vec{e}_q \rVert}
  3. 依赖度 deg(f)统计有多少其他文件引用了 f，被引用越多，越可能是连锁修改的中心节点。
    deg(f)=∣{g:g 引用 f}∣\text{deg}(f) = \left| \{ g : g \text{ 引用 } f \} \right|
  4. 体量惩罚 log(size)大文件会占掉大量上下文窗口，取对数是为了缩小量纲差距、温和地降权。
    −γ⋅log⁡(size(f))-\gamma \cdot \log(\text{size}(f))

模式对比：四支施工队

同一套房，业主有四种请人方式。第一，自己抄起锤子干——纯手动编程，最累；第二，请老李站旁边递锤子——Tab 补全，你敲到一半他帮你补一锤；第三，请个顾问只动嘴——Chat 模式，说得好听，代码还得你自己贴回去；第四，请王工带整队进场——Composer，从图纸到施工全包，你只负责拍板确认。

这四种方式的本质差异是“谁在干活”。可以定义一个自动化率，衡量某种模式 M 下模型承担的工作比例：

Composer 模式还有一个隐藏价值：因为所有改动都集中在一个可审阅的 diff 里，人只需要审一次，而不是在四个文件之间来回切换。认知负担降下来了，改错的概率也随之下降。当然，王工的报价也更贵——Composer 消耗的计算资源远超一次补全，但对复杂任务，这笔投入换来的是整体质量，值。

A(M)=Cmodel(M)Cmodel(M)+Chuman(M)\displaystyle A(M) = \frac{C_{\text{model}}(M)}{C_{\text{model}}(M) + C_{\text{human}}(M)}
分子是模型完成的动作数，分母是模型加人工的总动作数。比值越高，模式越自主，人越省事。
  1. 自动化率 A模式 M 的自动化程度，取值在 0 到 1 之间。
    0≤A(M)≤10 \le A(M) \le 1
  2. 模型侧工作量模式 M 下 AI 完成的编辑、检索、规划等动作总数。
    Cmodel(M)=∑model 动作C_{\text{model}}(M) = \sum \text{model 动作}
  3. 人工侧工作量模式 M 下人工完成的定位、编写、粘贴、校验等操作总数。
    Chuman(M)=∑human 动作C_{\text{human}}(M) = \sum \text{human 动作}
  4. 比值含义Tab 补全时 A≈0.1（几乎全人工），Chat 时 A≈0（只说不做），Composer 时 A≈0.7（模型干大头、人工只审阅）。
    A(Tab)<A(Composer)<A(Agent)A(\text{Tab}) < A(\text{Composer}) < A(\text{Agent})

典型场景：什么时候该叫监理

不是所有活都值得请监理。换个门把手，你自己就能敲；但拆承重墙、全屋翻新、整栋楼统一换智能锁，一定得交给王工。编程世界同理：单行补丁、微调文案，Tab 补全足够；但下面场景天生属于 Composer。

新功能开发——加“登录”要同时动后端接口、前端页面、数据库表；跨文件重构——重命名一个公共函数，所有调用方必须同步改；技术栈迁移——从旧框架换到新框架，import 路径和调用语法全部重写；连锁修复——改一个接口，所有依赖它的文件都要跟着调整。这些场景的共同特征是“改动量大且文件间有强关联”。手动做，是 n 个文件每个都要编 m 行代码；用 Composer，是几轮对话的事。收益比可以写成：

判断标准很朴素：只要你的任务“牵一发动全身”，就值得叫监理进场。这与“房子要动结构”是同一个信号——改一处会牵扯出一串，才需要全局规划。

R=n×mt\displaystyle R = \frac{n \times m}{t}
n 是被改文件数，m 是每个文件的改动量，t 是与 Composer 的对话轮数。n 和 m 越大，Composer 的杠杆越明显。
  1. 分子 n×m传统方式下需要手工完成的总改动量，文件数和单文件改动量相乘。
    n×m=总改动量n \times m = \text{总改动量}
  2. 分母 t驱动 Composer 完成同样任务所消耗的对话轮数。
    t=描述+反馈+调整t = \text{描述} + \text{反馈} + \text{调整}
  3. 比值 R每一轮对话撬动的改动量，R 越大说明投入产出比越高。
    R=总改动量对话轮数R = \frac{\text{总改动量}}{\text{对话轮数}}
  4. 决策阈值当 R 小于 1 时，说明任务本身很小，不值得开 Composer。
    R>1⇒值得使用R > 1 \Rightarrow \text{值得使用}

实践要点：业主配合守则

王工再能干，也怕遇上甩手掌柜型业主。需求说不清——“我想要好看点”——图纸画出来必定不是你要的样子。好业主都懂得四件事。第一，把需求说具体：告诉 Composer“把 UserService 重命名为 AccountService，并同步所有引用”，远好于“优化一下用户模块”。

第二，逐条审阅 diff：非预期的改动要当场指出，确认后再应用；第三，及时处理冲突：若你本地已有未提交的修改，与 Composer 方案冲突，先手动合并再继续执行；第四，跑测试验证：应用改动后运行测试，确认没有改坏任何功能。这四件事里，指令质量对成功率的影响呈典型的饱和曲线：

所以别当甩手掌柜，但也不必过度焦虑措辞。把需求说清楚、把 diff 看仔细，剩下的信任王工就好——业主的配合方式决定装修的最终质量。

Psuccess=1−e−kQ\displaystyle P_{\text{success}} = 1 - e^{-k Q}
随着指令质量 Q 提高，成功概率先快速上升，之后趋于饱和——指令写到“够用”即可，不必追求完美措辞。
  1. 成功概率 P_successComposer 方案一次通过人工审阅并正确落盘的概率。
    0≤Psuccess≤10 \le P_{\text{success}} \le 1
  2. 指令质量 Q需求描述的具体程度、上下文提供程度、约束明确程度的综合。
    Q=Q具体+Q上下文+Q约束Q = Q_{\text{具体}} + Q_{\text{上下文}} + Q_{\text{约束}}
  3. 指数形式 e^{-kQ}Q 很小时成功概率近乎线性爬升，Q 变大后增速放缓。
    e−kQ→Q→∞0e^{-kQ} \xrightarrow{Q \to \infty} 0
  4. 速率常数 k由当前模型能力决定的增长速率，k 越大，同样的描述能换来更高的成功率。
    k>0k > 0

局限与未来：装修队的明天

王工也有干不了的活。老城区那些没有图纸的危楼——代码结构混乱、文档缺失的遗留项目——他进去也发怵。户型太大——几百万行代码的大仓库——他一次看不过来，只能分批处理。核心瓶颈是上下文窗口：Composer 一次能“看见”的代码量，取决于模型窗口能装多少 token（文本切分的基本单位）。

而当前主流自注意力机制的计算成本随 token 数平方增长。这份“平方律”是悬在所有大模型应用头顶的物理天花板：

明天呢？行业正在朝两个方向走。一是把单打独斗的监理升级为“多智能体施工队”：一个智能体做规划，一个读代码找漏洞，一个写修改，一个做评审，各司其职再汇总；二是让 AI 跨阶段承接更多工程职责，从“改代码”走向“自主完成一个小型工程”。技术上越来越复杂，但每一步都需要开发者的审阅与判断，就像再智能的施工队，业主也得在验收单上签字。王工的故事告诉我们：监理不是取代业主，而是把业主从琐碎施工中解放出来，去关注真正重要的决策。

Cattn=O(n2)\displaystyle C_{\text{attn}} = O(n^2)
n 是上下文里的 token 数量。窗口翻倍，计算成本变成四倍，所以“把整个代码库无脑塞进去”在物理上行不通，必须靠检索和裁剪来取舍。
  1. 大 O 记号 O(·)描述计算量随规模增长的量级，只看“趋势”不看常数。
    Cattn=O(n2)C_{\text{attn}} = O(n^2)
  2. token 数 n上下文窗口能容纳的文本单元数量，代码、注释、diff 都按 token 计费。
    n=上下文 token 总数n = \text{上下文 token 总数}
  3. 平方增长含义n 从 1 万变 2 万，计算成本从 1 亿量级变 4 亿量级。
    n2→n 翻倍4n2n^2 \xrightarrow{n \text{ 翻倍}} 4n^2
  4. 工程缓解手段语义检索、上下文压缩、多轮分批，都是在平方律下做取舍。
    C实际<O(n2)C_{\text{实际}} < O(n^2)

AI 应用场景

电商系统跨模块重构

阶段：代码重构与工程变更

解决的问题：传统方式要手工搜索所有调用 UserService 的文件，逐个修改且容易漏改，尤其当调用方分布在订单、支付、物流三个模块时，漏一个就编译失败，排查又得花半天。

具体案例：某电商团队用 Composer 输入“把 UserService 重命名为 AccountService，并同步更新所有引用”。Composer 扫描三个模块，生成 12 个文件的改动 diff，团队逐条审阅后确认，10 分钟完成了原本要一下午的重构。整个过程中没有出现漏改，因为 Composer 的检索覆盖了全部引用点。

博客平台新功能整体落地

阶段：新功能开发与多文件联动

解决的问题：新功能往往牵涉路由、页面组件、侧边栏入口、菜单链接等多个文件，手动逐个创建容易遗漏关联，导致功能上线后入口缺失或页面 404。

具体案例：给博客加“归档年表”页面，传统做法是手动创建路由文件、页面组件、侧边栏入口、菜单链接四个文件。用 Composer 输入“新增 /archive 页面，按年份展示所有文章，并把入口加到导航栏”，一次生成四个文件的改动方案，审阅后确认，功能完整落地。

遗留项目技术栈迁移

阶段：技术栈迁移与兼容性修复

解决的问题：把老项目的 jQuery 代码迁移到原生 ES6，涉及几百处 DOM 操作改写。手动改不仅耗时，还容易把事件绑定的上下文逻辑改坏，回归测试成本极高。

具体案例：某团队用 Composer 按模块分批迁移，每个模块输入明确的迁移指令，如“把 $('.btn').click(fn) 改写为 addEventListener 形式”。每批生成 diff 供审阅，配合回归测试验证，最终三个月的工作量压缩到三周完成。

Python 演示

python62 行
import difflibimport pathlibimport reimport sys  class ComposerLikeRefactor:    def __init__(self, root_dir, pattern, replacement):        self.root_dir = pathlib.Path(root_dir)        self.pattern = pattern        self.replacement = replacement        self.plans = []        self.updated_files = []     def scan_files(self):        return list(self.root_dir.rglob("*.py"))     def collect(self):        for f in self.scan_files():            text = f.read_text(encoding="utf-8")            if self.pattern in text:                after = re.sub(self.pattern, self.replacement, text)                if after != text:                    diff = "".join(difflib.unified_diff(                        text.splitlines(keepends=True),                        after.splitlines(keepends=True),                        fromfile=str(f),                        tofile=str(f)                    ))                    self.plans.append((f, diff, after))        return self     def show_plan(self):        for f, diff, _ in self.plans:            print("=" * 60)            print("文件:", f)            print(diff)        return self     def apply(self, confirm=True):        if confirm:            answer = input("确认应用以上 %d 处修改? [y/N] " % len(self.plans))            if answer.lower() != "y":                print("已取消")                return self        for f, _, after in self.plans:            f.write_text(after, encoding="utf-8")            self.updated_files.append(str(f))        return self     def report(self):        print("=" * 60)        print("已更新文件 %d 个:" % len(self.updated_files))        for p in self.updated_files:            print("  -", p)        return self  if __name__ == "__main__":    root = sys.argv[1] if len(sys.argv) > 1 else "demo_project"    work = ComposerLikeRefactor(root, r"\bprint\((.+?)\)", r"logger.info(\1)")    work.collect().show_plan().apply(confirm=True).report()
目的：模拟 Composer 的多文件重构工作流——扫描项目、生成跨文件 diff 方案、用户确认后应用并汇报，完整复刻“规划→审阅→应用→汇报”四步流程。
  1. self.plans.append((f, diff, after))把文件路径、diff 预览、修改后内容打包成一条“施工方案”，等待用户审阅。
  2. after = re.sub(self.pattern, self.replacement, text)用正则替换模拟模型生成修改内容的过程，相当于 AI 的“落笔”。
  3. diff = "".join(difflib.unified_diff(...))用标准库生成 diff 预览，让用户像看装修图纸一样逐行审阅。
  4. if self.pattern in text:先用简单包含判断快速筛选候选文件，模拟 Composer 的语义检索粗筛。
  5. if answer.lower() != "y":用户不确认就绝不写盘，守住“先审阅再应用”的安全边界。
  6. f.write_text(after, encoding="utf-8")只有确认后才会真正改写文件，对应 Composer 应用的最后一公里。
  7. work.collect().show_plan().apply(confirm=True).report()一行链式调用复刻 Composer 的完整工作流。

常见误区

误区“我之前用 Chat 问问题，Composer 不就是多开几个文件、把答案往里面贴吗？感觉没什么区别。”

正解Chat 只给建议，代码还得你自己贴回文件；Composer 会主动检索代码库、规划方案、直接产出跨文件的 diff，你审阅后可一键应用。差别好比顾问动嘴与监理带队施工——顾问说“这墙能拆”，监理直接把拆墙方案和施工队都带来了。

为何常见：因为界面都是对话框，用户容易把“会说话”等同于“能干工程”，忽略了背后文件写入与方案管理能力的差异。

误区“让它同时碰好几个文件，万一逻辑全乱了怎么办？我宁可自己手动改，更放心。”

正解Composer 的所有改动先以 diff 形式呈现，你逐条审阅后才落盘；不确认不会改动任何文件。它等于先把施工图纸摊开给你过目，而不是直接抡锤子。可回溯、可回滚，比手动复制粘贴更可控。

为何常见：对“AI 自主改文件”的本能警惕，加上没意识到 diff 审阅是流程内置的强制环节，把“自动”误解为“失控”。

误区“AI 生成的 diff 肯定是对的，我每次都直接全部应用，省时间。”

正解diff 审阅是 Composer 工作流的灵魂。模型可能对需求理解偏差、可能改到不该动的文件、可能在边界情况下出错。跳过审阅等于业主不看图纸就让施工队开工，出了问题返工成本更高。审阅不是流程仪式，是质量闸门。

为何常见：AI 主动生成的方案看起来完整，容易让人放松警惕；加上审阅需要精力，就想“赌一把”，结果常在非预期改动上翻车。

误区“反正它能跨文件改，我把整个系统重构的需求一次全告诉它，它应该能全搞定。”

正解上下文窗口和模型注意力都有限，一次塞入超大目标容易“顾头不顾尾”。正确做法是拆成若干有边界的子任务，逐个用 Composer 完成并验证，像装修也分水电、木工、油漆多阶段验收一样。大而全的指令反而产出不可控的方案。

为何常见：高估了模型的上下文能力，把“能跨文件”误解为“能无限跨文件”，忽略了物理上的窗口限制。

误区“Composer 能自己规划、自己改文件，这不就是 AI 程序员完全替我干活了吗？”

正解Composer 在“规划与执行”上自主，但每个环节都保留人工审阅与中止权，目标场景是“可审阅的整体变更”。而 Agent 技术追求更长链路、更高自主度的任务闭环，两者是同一方向上的不同阶段，安全边界完全不同。

为何常见：看到“智能体”“自主”一类词就往科幻方向联想，忽略了产品设计上人为保留的控制点，把阶段当成了终点。

面试题

Q1. Cursor 的 Composer 与 Tab 补全最本质的区别是什么？

单选题 · easy

  • A.Tab 补全只能补全当前行的文字
  • B.Composer 能规划跨文件整体变更← 正确答案
  • C.Composer 完全不需要人工审阅
  • D.Tab 补全无法生成任何代码

答案：B。Tab 补全是“递锤子的工匠”，只看得到光标附近；Composer 是“带队施工的监理”，把自然语言需求变成跨文件的可审阅变更方案。C 错误，审阅是 Composer 流程的强制环节；D 错误，Tab 补全也能生成单点代码。

Q2. 用户对 Composer 说“把 UserService 重命名为 AccountService”，Composer 最先输出的是什么？

单选题 · easy

  • A.一张完整的设计文档
  • B.待改动文件的方案计划← 正确答案
  • C.已经改写完成的最终代码
  • D.一份用户的使用手册

答案：B。Composer 遵循“规划先行”：先检索代码库、列出受影响的文件清单与改动计划，然后生成 diff 供审阅，确认后才落盘。A 太宽泛，C 顺序错误（先方案后执行），D 与任务无关。

Q3. 以下哪一项不属于 Composer 的核心特征？

单选题 · easy

  • A.支持以自然语言描述编程目标
  • B.能够跨多个文件产生连贯改动
  • C.所有修改默认直接写入并提交← 正确答案
  • D.提供整体 diff 供用户审阅确认

答案：C。C 是典型的错误理解。Composer 默认先出方案、审阅后才应用修改，不会不经确认就写入提交。A、B、D 都是它的核心特征——自然语言入口、跨文件能力、可审阅的整体变更。

Q4. Composer 工作流程的正确顺序是？

单选题 · mid

  • A.规划方案、描述需求、审阅改动、应用修改
  • B.描述需求、规划方案、审阅改动、应用修改← 正确答案
  • C.描述需求、应用修改、规划方案、审阅改动
  • D.审阅改动、规划方案、描述需求、应用修改

答案：B。对应“听需求→画图纸→业主确认→施工”四步：先输入自然语言需求，再生成跨文件的方案与 diff，审阅通过后应用。其他选项顺序均与工作流不符，尤其 C 把应用排在规划之前，逻辑颠倒。

Q5. Composer 在理解大型代码库时，通常会用到哪些技术手段？

多选题 · mid

  • A.代码索引与语义检索辅助定位← 正确答案
  • B.分析文件之间的依赖关系网络← 正确答案
  • C.对上下文进行裁剪与取舍← 正确答案
  • D.自动部署应用到生产服务器

答案：ABC。A 对应“找文件”，B 对应“理关系”，C 对应“塞窗口”，三者共同构成 Composer 前置理解能力。D 是部署环节，不属于理解代码库的手段，是典型干扰项。

Q6. 模型上下文窗口的 token 容量从 n 扩大到 2n，自注意力计算成本大致如何变化？

单选题 · mid

  • A.基本不变，保持恒定
  • B.线性增长到原来的两倍
  • C.平方增长到原来的四倍← 正确答案
  • D.指数爆炸到无法计算

答案：C。自注意力成本是 O(n²)（随规模平方增长），n 翻倍则成本变为 4 倍。这正是 Composer 无法把整个巨型代码库一次性塞进上下文的原因，也是语义检索和裁剪存在的意义。

Q7. 以下哪些场景适合优先使用 Composer？

多选题 · mid

  • A.接口变更后同步所有调用方文件← 正确答案
  • B.新功能涉及路由页面数据库等多个文件← 正确答案
  • C.跨多个文件重命名一个公共函数← 正确答案
  • D.修改当前光标后的一个错别字

答案：ABC。A、B、C 都是“多文件强关联”任务，符合 Composer 的定位。D 是单点微调，用 Tab 补全或手动改更快，开 Composer 属于杀鸡用牛刀。

Q8. 为什么在 Composer 中先审阅 diff 再应用，整体上反而更节省时间？

单选题 · hard

  • A.审阅过程能加快代码的编译速度
  • B.提前发现问题能避免更大范围的返工← 正确答案
  • C.diff 会自动修复所有已存在的测试错误
  • D.审阅能让模型记住并学习用户的偏好

答案：B。成本公式 C_total = C_plan + ΣC_edit + C_rework·p_error 说明：返工成本远高于审阅成本，审阅会压低出错概率 p_error，从而降低期望总成本。A、C 没有依据，D 不是主要收益。

Q9. 与 Chat 模式只提供建议相比，Composer 在工程实践层面的本质升级是什么？

单选题 · hard

  • A.把零散建议升级为可审阅的整体变更← 正确答案
  • B.把代码生成速度提升了成百上千倍
  • C.让模型完全不再需要任何人工干预
  • D.把每个文件都改成统一的代码风格

答案：A。Chat 止步于“说”，Composer 推进到“做”——生成跨文件 diff、可审阅、可应用、可回滚，把 AI 从顾问变成施工监理。B 不是本质，C 违背人工审阅机制，D 只是格式化工具的能力。

Q10. 团队用 Composer 重构支付模块，所有 diff 都通过了单元测试，上线后仍出现金额精度错误。以下分析中合理的是？

多选题 · extreme

  • A.生成式修改可能遗漏了测试未覆盖的边界情况← 正确答案
  • B.Composer 完全不会引入任何逻辑层面的错误
  • C.团队可能跳过了人工审阅直接合入了改动← 正确答案
  • D.单元测试通过证明线上问题与 Composer 无关

答案：AC。测试只能证明覆盖到的用例正确，不覆盖的边界仍可能出错（A 对）；跳过审阅会漏掉非预期改动（C 对）。B 绝对化错误；D 把测试的有限性当成充分性，犯了归因错误。