1. 先想清楚AI 助手到底是代笔还是陪练我第一次把 ChatGPT 这类对话式 AI 助手拖进日常编码流程动机特别朴素——不想写重复的样板代码。半年后回头看真正让我效率翻倍的反而不是它帮我敲了多少行代码而是它在我含糊其辞的时候把我问住了。这两种体验差别极大前者是代笔后者是陪练而大部分人对 AI 编程助手的失望都源于用代笔的期待去要求一个陪练。这个标题里的智能伙伴和思维导师其实是两个层级。智能伙伴解决的是手速问题脚手架、正则、序列化、边界判断、命名建议、日志格式、单元测试骨架这些活儿它的确又快又稳。思维导师解决的是判断问题方案有几种、每种代价是什么、我漏了哪个异常分支、这个抽象是不是过度设计。前者省时间后者省返工。而返工往往比打字贵得多所以我现在的用法重心明显偏向后一层。这篇文章适合三类人看刚入行、还没建立起自己判断体系的新人可以参考我下面的提示词结构和提问顺序工作三五年、被重复劳动磨得没脾气的中间层可以看看怎么把琐碎活外包出去带人的同学可以看看怎么用 AI 辅助做代码评审和方案复盘。全文讲的都是方法论和实操细节不讲玄学也不吹神效。1.1 三个角色定位决定了你该怎么开口我把 AI 助手的使用方式粗略分成三种角色每种角色的对话方式、验收标准、风险点都不一样。搞混了角色就会出现我让它写个模块它写了一堆看起来对但跑不通的东西的经典翻车。角色你输入的形态它输出的形态验收方式主要风险打字机明确到函数签名级别的需求完整代码块直接跑用例边界遗漏、API 幻觉陪练一段思路 你的约束追问、备选方案、代价清单你自己判断取舍被它的措辞带偏审阅者已有可运行代码 上下文问题清单、可疑点逐条核实抓不住业务语义打字机模式最容易上手也最容易让人产生AI 真强的错觉。你把一个写得极其详细的函数需求贴进去它给你的代码八成能跑。但问题在于能把需求写得那么详细的人本身就不太需要它写这段代码了。真正有价值的场景是中间那段——你有模糊的想法需要有人帮你把边界逼出来。陪练模式的关键动作是让它先问。我现在开一个新话题第一句几乎固定是先别写代码你反问我三个问题确认需求边界。它问出来的三问经常能戳到我漏掉的东西比如并发情况下这个方法会被重入吗空列表是返回空还是抛异常这个字段是必填还是可以延迟加载。这三个问题本身就值回票价了。审阅者模式是最被低估的。写完一段逻辑复杂的代码把它和上下文一起贴过去要求只找问题不要重写通常能捞出两三类我自己视而不见的疏漏——空值穿透、异常吞掉、循环里做了数据库查询。它不会理解你的业务语义但机械性的疏漏它比人眼稳定。1.2 我在真实项目里踩过的两种极端第一种极端是全盘信任。某次做数据导入我把一段解析逻辑丢给它代码看着干净利落跑小样本完全正常。上线后遇到一个十万行的脏数据文件内存直接飙上去——它在循环里每次都新建了一个列表做浅拷贝。这种错误人也会犯但人犯的时候往往有这段代码我写的我知道哪里危险的警觉而 AI 给的代码你天然缺乏这种肌肉记忆。第二种极端是全盘否定。有一阵子我看到 AI 给的代码就下意识觉得肯定有坑宁可自己从头写。结果是我花了两小时手写一个树形结构的扁平化它三十秒给了个递归加缓存版本我对着看了五分钟发现确实比我的干净。偏见本身也是成本而且这个成本是隐性的你不会意识到自己慢了多少。现在我给自己定的规矩是代码可以信结论不可信结构可以信边界不可信。它给的架构建议、命名建议、拆分方式通常有参考价值它给的具体 API 调用、异常处理、并发行为一律当草稿对待必须自己跑一遍。这个区分标准简单粗暴但极其有效。1.3 什么时候该果断放下它有三类场景我会直接关掉对话框自己干因为用 AI 反而更慢。第一类是高度依赖内部上下文的改动。比如某段代码为什么写成这个古怪样子——因为三个月前有个特殊的兼容需求。这种历史包袱你没法学给 AI 讲清楚讲了它也只能按你说的做那还不如自己动手。第二类是细粒度调优。性能瓶颈定位到某一行之后剩下的工作往往是把这行换成另一种写法然后压测对比这种活儿需要极短反馈循环人和工具来回切换的开销大于收益。第三类是需要承担责任的判断。选型、架构分层、对外接口设计这些最终签字的是你。AI 可以给你列清单但不该替你做决定尤其不该替你做我们放弃这个方案因为代价太高这种决定。2. 提示词不是咒语把需求拆成机器能接住的形状很多人抱怨AI 写的代码不能用其实问题往往出在输入。你给它一句帮我写个用户登录它能做的只能是猜——猜你的技术栈、猜你的密码存储方式、猜你要不要限流、猜失败几次锁定。猜错的概率远大于猜对于是你觉得它不行。这不是它笨是你给的信息熵太高。提示词的本质不是咒语是需求文档的极简版。你在公司写需求评审的时候会写什么就应该在对话里写什么只是可以更口语化、更短。2.1 三要素上下文、约束、验收标准我总结下来任何一个靠谱的代码请求至少要包含三样东西缺一样翻车率就明显上升。上下文回答这是什么环境。语言版本、框架、现有代码风格、相关的数据结构、这段代码在整体流程里的位置。我习惯一次性把关键信息压缩成几行贴上去比如Python 3.11无第三方依赖项目里已有Result数据类和fetch_user函数风格偏函数式不用类。这几行字能挡掉大半的它给我用了个我没装的库。约束回答不能做什么。这是最容易被忽略、但收益最高的一环。不许用某个库、不许改函数签名、不许引入全局状态、复杂度不能超过多少、必须保持向后兼容。约束写得越具体它的输出越收敛。验收标准回答怎么算做好了。这是区分业余和专业的分水岭。不要说写个排序函数要说输入是可能含重复元素的整数列表返回去重后升序列表输入为空返回空列表不修改入参时间复杂度尽量控制在线性对数级别。有了验收标准它自己就会去覆盖边界。提示如果一次对话里你发现自己在反复纠正同一个问题八成是约束没写清楚而不是它理解力不行。停下来说清楚约束比来回改五轮省时间。2.2 逐层收敛别一次把整个系统塞进去新手最常见的操作是把三千行项目代码粘贴进去说帮我找 bug。结果要么它抓了三个空格缩进问题要么它开始编造你没写的函数。这不是能力问题是信息过载。我的做法是分层递进每一层只解决一个粒度的问题架构层只贴目录结构、模块职责说明问这个分层有什么明显问题。模块层贴单个文件的完整代码问这个模块的职责是否单一有没有隐藏耦合。函数层贴单个函数和它的调用方问边界条件是否覆盖完整。行级贴几行有疑问的代码问这里的并发安全吗。每层之间的信息量控制在它能够完全读懂的范围内。我的经验阈值是单次粘贴代码控制在 200 行以内超过这个量它开始出现记得前面忘了后面的情况。这个数字跟模型上下文长度无关跟注意力分配有关——上下文再长能真正用上的有效信息也是有限的。2.3 一份我常用的提示词骨架下面这段是我从无数次调整后沉淀下来的模板直接抄就能用按需替换方括号里的内容。【角色】你是一位有十年经验的[Python/Java/前端]工程师擅长在既有代码库中做最小改动。 【上下文】 - 语言与版本[Python 3.11] - 依赖限制[只用标准库不允许新增第三方包] - 现有相关代码[贴 50 行以内的相关代码]- 数据规模[单次处理量约 2 万条日均调用 500 次] 【任务】 [用一两句话描述要做的事不要写实现思路] 【约束】 - 不修改现有函数签名与返回值结构 - 不引入全局可变状态 - 异常情况统一返回 Result.fail不抛未捕获异常 - 单次执行内存占用不超过 [XX MB] 【验收标准】 1. [输入 A期望输出 B] 2. [空输入的行为] 3. [异常输入的兜底行为] 【输出格式】 先给出你的思路和 2 个以上备选方案及各自代价等我确认后再写代码。最后那句先给思路等我确认是整段模板的灵魂。它把一次性的生成-返工循环变成了对齐-生成循环。多花一轮对话少改三轮代码这笔账很划算。2.4 五个高频反模式我几乎每天都见反模式一需求里带答案。用递归帮我实现这个树遍历——你已经在实现层面做了决策它只能照着写没法告诉你这棵树深度可能上千、递归会爆栈。反模式二一次问五个问题。一段消息里塞了优化性能、加日志、改命名、补测试、修 bug它的注意力会被摊薄通常只把最显眼的两三件做了。反模式三不给失败案例。只说这个函数有问题不说A 输入正常、B 输入返回错。它只能靠猜猜错你就觉得它笨。反模式四用形容词代替量化指标。优化一下性能和把单次耗时从 1.8 秒压到 100 毫秒以内得到的方案质量完全不在一个层次。反模式五不追问。它给了一个方案你看一眼觉得大概行就直接用了。正确姿势是追问一句这个方案在什么情况下会失效。这一问经常能让它自己把坑挖出来比你自己想半天快得多。3. 从需求到可运行代码一条完整的实操链路光讲原则容易空我把最近做的一个模拟项目完整走一遍。场景是内部工具需要一个日志解析模块把混合格式的文本日志解析成结构化记录然后按时间窗口聚合统计。数据量不大两万行左右但格式很脏有几种历史遗留的变体。3.1 第一步永远是澄清需求边界我没有直接说帮我写日志解析。我的第一句话是我要做一个日志解析模块输入是文本行列表输出是结构化记录列表。在动手之前请你反问我五个问题覆盖你没把握的地方。它问的五个问题里有三个是我确实没想清楚的格式不认识的行怎么办跳过还是报错、时间戳没有时区的怎么处理、字段缺失是给默认值还是标 null。这三个问题逼我回去翻了一遍历史日志样本发现大约 3% 的行是残缺的。于是我在需求里补了一条残缺行统一收集到 rejected 列表不中断整体流程最后统计拒绝率。这一条如果没想清楚后面整个模块的异常处理都得推倒重来。这就是我说的思维导师价值——它不一定比你懂业务但它比你更愿意把模糊地带摊开。人写代码容易急着开工AI 不会急。3.2 接口先定实现后填需求边界清楚了第二步不是写实现是定接口。我要求它只输出函数签名、数据类定义和文档字符串不写任何函数体。这一步的产出大概是这样的from dataclasses import dataclass, field from datetime import datetime from typing import Iterable dataclass(frozenTrue) class LogRecord: ts: datetime level: str source: str message: str raw: str dataclass class ParseReport: records: list[LogRecord] field(default_factorylist) rejected: list[tuple[int, str]] field(default_factorylist) property def reject_rate(self) - float: total len(self.records) len(self.rejected) return len(self.rejected) / total if total else 0.0 def parse_lines(lines: Iterable[str]) - ParseReport: 解析混合格式日志行无法识别的行进入 rejected不抛异常。 ...接口定完我先自己看了一遍rejected存的是(行号, 原始内容)这个设计比存异常对象好因为后面要做人工回捞。frozenTrue是我加的理由是这个记录一旦产出就不该被下游改动。接口阶段花十分钟能省掉后面两小时的返工因为所有实现细节都被约束在一个稳定的外壳里了。3.3 让它写测试比让它写代码更值钱这是我整个流程里最推荐的改动先让它写测试用例你确认测试再让它写实现。我给出的指令是基于上面的接口写 12 个 pytest 用例覆盖正常行、字段缺失行、时间戳格式异常行、空输入、只有空白的行、超长行超过 10000 字符、中文与英文混排、混入不可打印字符、以及三种历史格式变体。它给的 12 个用例里有 2 个我自己没想到一个是同一行里出现两个时间戳该取哪个一个是行尾带\r\n和只有\n的差异。前者是真实存在的情况——应用层拼接日志时会重复打时间戳后者在跨平台文件里极其常见Windows 导出的日志带\r正则写不好就会把\r吃进 message 字段。有了这 12 个用例后面写实现就是纯体力活而且有了明确的完成信号——跑通全部用例就算完事。这比看着差不多就行强太多。实操心得让 AI 写测试的时候明确要求每个用例只用一行 assert不要写辅助函数。用例越扁平出问题时定位越快。它天生喜欢抽象你不约束它它能给你套三层 fixture。3.4 重构阶段用对比法不要用优化一下第一版实现跑通测试后我做了一轮重构。常见的错误指令是优化这段代码太模糊。我用的是对比法下面给出两版实现请从可读性、异常安全性、最坏情况性能三个维度对比指出各自会在什么输入下失效。我拿到的对比反馈里有一条很关键第一版用了一长串if/elif判断格式随着格式变体增加会持续膨胀而且判断顺序会影响结果——如果一个宽松的正则排在前面会把本该匹配严格格式的行先吃掉。第二版改成了按格式特征做分派每种格式自带校验函数匹配失败自动落到下一个。这个改动不大但把扩展性从改函数体变成了加一个注册项。这里有个细节值得说我要求它给出会在什么输入下失效它指出了第二版的一个隐患——如果一行同时满足两种格式的特征会走第一个注册的可能解析出错。这个隐患在我的实际数据里确实出现过一次占比约 0.2%。虽然是极小概率但至少我知道了这个风险的存在而不是稀里糊涂上线。3.5 一个性能数字的推导过程聚合统计那部分最初版本是双循环对每条记录遍历所有时间窗口判断归属。数据量两万条、窗口两千个理论比较次数是四千万次。实测耗时约 1.8 秒慢得离谱。我把它贴给 AI 时没有说太慢了帮我优化而是给了数据两万条记录两千个时间窗口当前是双层循环实测 1.8 秒。目标压到 100 毫秒以内。数据特点记录已按时间升序窗口大小固定。它给的方案是把窗口起点做成哈希表每条记录通过时间戳整除窗口长度直接定位到窗口索引复杂度从 O(n·m) 降到 O(n)。这个思路本身不新鲜但它在回复里补了一句我没考虑到的因为记录已排序可以用一个游标单调推进连哈希表都省了。改完之后实测 40 毫秒左右。这个例子的重点不在优化技巧而在于你给的数据越具体它的方案越具体。太慢了只能换来用缓存吧这类空话给出规模、目标、数据特征才能换来针对性的方案。4. 把它当思维导师用提问换取判断力前面讲的多是让它干活这一节讲让它陪你思考。这部分没法量化收益但长期看价值更大因为它训练的是你自己的判断力。4.1 反问式用法让它先问你三个问题这个技巧我逢人就推荐。任何稍微复杂一点的任务第一句都加先别动手反问我三个问题。它问出来的问题往往精准命中你思维里的空白区。举个具体例子。我在设计一个缓存淘汰策略时本来的想法很简单按访问时间做 LRU。让它反问它问了三个缓存的 value 计算成本高吗访问分布是长尾还是均匀内存上限是硬的还是软的。这三个问题直接改变了方案——因为 value 计算成本低缓存的意义不大访问分布是长尾LRU 会把大量一次性数据挤进缓存又很快淘汰。最后我改成了按访问频次加权的方案缓存命中率从 40% 出头提到了 70% 左右。注意它没有告诉我答案它只是让我自己发现了问题。这就是导师和工具的区别。4.2 逼它列代价而不是列好处AI 有个天然倾向你问A 方案好不好它会告诉你 A 方案好在哪。这是训练数据带来的讨好倾向不是它真的认为 A 好。破解办法是换个问法不问好不好问什么时候不该用。我常用的句式有三句效果很稳定这个方案在什么场景下会明显变差给我三个具体例子。如果团队只有两个人维护这个设计还成立吗把 A 和 B 放一起列出各自的隐性成本不要列优点。最后一句特别好用。让它列隐性成本它会说出一些很实在的东西比如引入了额外的抽象层新人理解成本上升需要额外的监控指标否则出问题无法定位调试链路变长本地复现困难。这些东西在技术选型的文档里通常不会写但它们才是真正决定项目能不能维护下去的因素。4.3 啃陌生技术栈的正确姿势我最近需要在一个完全没接触过的生态里写一个小工具。传统的学习路径是看官方文档、找示例、跑 demo大概要一两天才能上手。我的做法是把节奏压缩了一下第一步让它用一段话讲清楚这个生态的核心抽象是什么和[我熟悉的某个东西]最像的地方在哪最不像的地方在哪。类比是理解的捷径而它很擅长找类比。第二步让它给一个 30 行以内、能直接跑的最小可运行示例不要任何工程化包装。这一步的目的是建立我改一行会发生什么的直觉不是学最佳实践。第三步也是最关键的一步列出新手在这个生态里最容易犯的五个错误每个错误给一个错误写法和正确写法。这一步价值极高因为文档通常只讲正确用法不讲常见错误。我照着这五条检查自己的代码避开了三个坑。第四步才开始正经写业务代码边写边问。这套流程下来我大概半天就能写出能用的东西。速度的秘诀不在于学得快而在于跳过了大量暂时用不上的知识等真正需要时再回头补。4.4 用评审视角做自我校验写完一个模块我有个固定动作把代码贴过去配一句话——假设你是要接手这段代码的人请指出三处你会在 code review 里打回的地方按严重程度排序。这个指令的精妙之处在于假设你要接手。如果只说找 bug它会盯着语法和边界加上接手这个前提它的关注点会转向可维护性——命名是否达意、副作用是否隐蔽、错误信息是否有用、有没有留下看不懂为什么这么写的地方。我拿到的反馈里出现频率最高的三类是函数做了太多事、异常被静默吞掉、魔法数字没有解释。这三类恰好也是人类评审最常提的。区别在于人评审要等同事有空AI 评审随时可以。5. 高频翻车现场与排查手册用了这么久翻车类型其实高度集中。我把它们整理成速查表遇到问题先对号入座比盲目重试快得多。5.1 幻觉接口看起来最像真的错得最离谱这是最危险的一类。它会给你一个参数名、方法名、配置项格式完全正确命名风格完全符合那个库的习惯但这个东西根本不存在。危险在于它太像真的你不去查文档直接用了报错信息还特别绕容易让人以为是环境问题。我的防线有三层。第一层是凡是涉及外部库的调用一律要求它给出对应的官方文档链接或版本号它给不出来或者给得含糊就标记为待验证。第二层是先跑一个最小验证五行代码验证这个 API 存在且行为符合预期再往业务代码里写。第三层是优先让它用标准库标准库的 API 相对稳定幻觉率低得多。有个细节值得注意同一个 API它在不同轮对话里可能给你不同的签名。这不是它记错了是不同版本的训练数据混在一起。所以明确告诉它你的版本号能大幅降低这类问题。5.2 边界条件它总在正常路径上表现优异给它一个函数需求它写出来的主逻辑通常很漂亮边界处理则经常敷衍。典型表现空集合没判断、除零没防、负数索引没考虑、字符串截断没处理多字节字符。我的对策很直接在验收标准里把边界逐条列出来而不是指望它自己想到。我常用的边界清单是这几类空、单个、极多、超长、含空白、含特殊字符、并发访问、重复调用、依赖失败。每类至少要求一个用例。这份清单是我踩坑踩出来的比任何最佳实践文档都好使。5.3 上下文漂移聊到第十轮它开始记错前面的约定长对话必然出现这个问题。你在第一轮说了不要用类到第十轮它又开始写 class。这不是它故意违背是早期信息在长上下文里的权重衰减了。解法是把关键约束固定在每一轮的开头。我习惯在每轮消息前加一行简短的约定回顾比如约定函数式风格、不新增依赖、返回值统一用 Result、异常不外抛。这一行不到三十个字但能显著提升一致性。另一个办法是主动重置。当话题从模块 A 转到模块 B我会新开一个对话把必要的上下文重新贴一遍而不是在旧对话里继续。旧对话里那些已经完成的讨论对新任务来说是噪音。5.4 一张排查速查表现象最可能的原因处理动作报错说方法不存在API 幻觉或版本不符查官方文档确认版本先跑最小验证代码能跑但结果不对边界条件未覆盖补验收标准让它先写测试再写实现改了五轮还是不对约束没写清或上下文漂移重开对话重贴上下文与约定输出越来越敷衍单次信息量过大拆分任务一次只解决一个粒度风格和项目不一致没给现有代码样例贴 20 行同项目代码作为风格参照引入未安装的依赖没写依赖限制明确只用标准库或列出白名单测试通过了但心里没底测试是它自己写的标准偏松自己补两条刁钻用例专挑异常路径注意最后一行是我最想强调的。让 AI 写测试有个隐患——它写的测试和它写的实现出自同一个理解如果理解错了测试也会跟着错你还能看到一片绿。所以关键模块一定要自己补一两条刁钻用例专挑它可能没想到的路径。这两条用例才是真正的守门员。6. 把 AI 助手接进日常研发流单次对话的技巧容易学难的是把它变成稳定的日常习惯。我现在的流程里AI 助手出现在四个固定节点每个节点有明确边界。6.1 开工前需求澄清与方案对比这个节点的产出是一段话的方案说明不是代码。内容包括要做的事、边界在哪、有哪两三个备选方案、各自主张什么、我选哪个以及为什么。这段说明我会直接贴进任务描述里后面无论是自己写还是让别人接手都不用重新想一遍。这一步的价值在时间维度上特别明显。写这段说明大概花十分钟但它能挡掉后面半天的方向性返工。方案错了代码写得再漂亮也是白写。6.2 编码中碎片化求助不打断心流编码阶段我用得很克制只在三种情况开口想不起某个标准库的用法、需要一段样板代码、卡在一个没头绪的报错上。这三种情况共同特点是目标明确、边界清晰问完就能继续干活不会打断思路。反面例子是帮我设计这个模块。这种问题一旦开口很容易陷入十几轮的来回讨论写着写着思路就散了。设计类的问题我会挪到 6.1 那个节点专门留时间做不在编码时穿插。6.3 提交前一道机械疏漏的闸门这是我最坚持的一个习惯。git commit之前把本次改动的 diff 贴过去配一句只列出你会打回的问题不要重写代码不要夸奖。它给出的问题清单里最常见的三类调试用的打印语句没删、异常分支里只写了pass、临时变量名没改。这三类问题人类评审也会提但它们属于机械性疏漏用人工时间去抓实在浪费。让 AI 当这道闸门人评审就可以专注在逻辑和设计上。这一步有个小技巧要求它按严重程度排序并且明确说如果没有严重问题就直说没有。不这么要求它会为了显得有用而硬凑几条反而增加噪音。6.4 复盘时把踩过的坑沉淀成规则每隔一段时间我会把这段时间遇到的问题汇总起来让它帮我归类下面是我这段时间遇到的十个问题帮我归类并提炼成五条可以写进团队规范的短句。这一步的产出是给自己的不是给 AI 的。比如我从这类复盘里提炼出的几条外部依赖调用必须先做最小验证关键模块的测试必须自己补异常用例单次贴给工具的代码不超过 200 行约束条件写在每轮对话开头。这些规则积累下来比任何AI 使用指南都贴合自己的实际。6.5 权限与数据的边界意识这一段单独拎出来说因为它的代价可能最大。我的原则很明确内部业务逻辑、真实数据结构、密钥配置、用户信息一律脱敏后再上对话。脱敏不是简单删几行而是要做结构保留、内容替换。表名改成t_user这种泛化名字字段值换成明显的假数据业务规则用某个条件触发某个动作这种抽象描述代替。这样它依然能理解逻辑结构给出有效的建议。我一般会花两三分钟做这个准备工作。这两三分钟换来的是放心也是对自己项目的负责。图省事直接粘贴风险和你省下的时间完全不成比例。6.6 长期使用后我形成的几条习惯最后分享几条坚持了半年以上的习惯都是小事但叠在一起效果很明显。第一永远保留一个为什么的记录。每次采纳 AI 的建议我会在提交信息里补一句为什么这么改。半年后回头看这些记录比代码本身有价值——它记录的是判断过程而不是结果。第二不追求一次问对。早期我总想让提示词完美一次问出最优解。后来发现与其打磨提示词不如快速问三次、对比三个答案。三次粗糙的提问胜过一次精心设计的提问因为对比本身就是信息。第三每周留半天不用它。这个习惯有点反直觉但很有必要。完全依赖工具会导致自己的能力退化——尤其是从零开始想一个问题的能力。留出不用它的时间是给自己做体检看看哪些能力还在、哪些已经生锈了。第四把它当同事而不是神谕。同事给你的建议你会判断、会验证、会追问对 AI 也应该如此。我见过不少人AI 说了一句话就当成定论转头去跟别人争论。这种信任度给得太轻易了。我个人的实际体会是这类工具真正的价值不在帮你写代码而在帮你把想清楚的成本降下来。写代码只是最后一步前面那些澄清需求、对比方案、检查边界的活儿才是决定一个模块能不能活过三个月的东西。工具替不了你判断但它能让你有更多余裕去做判断——这个余裕才是效率提升真正发生的地方。