如果你手头拿到一套真正意义上的毛坯房——四壁水泥裸露，地上积着灰，连水电管线都没排——你会不会随手请一支装修队，跟人家说“你看着办，我信你”？我去年搭新项目时，就干了这么一件差不多的事：手里一个空空如也的代码仓库，相当于毛坯房，我把 pi agent 请了进来，随口说“从零开始帮我搭起来”。当时想法很简单：这玩意儿是当下最热门的 AI coding agent，自然语言说需求，它就能写代码、改文件、跑命令，我还操什么心。
事实证明，把 pi agent 当装修队，把空仓库当毛坯房，这个类比不但没有违和感，反而精准得可怕。装修有装修的坑，AI 编程 agent 有它自己的坑，而这两者的坑竟然高度同构——过度设计、偷偷改墙、用料货不对板、验收时才发现水电图全是错的。这篇文章就是把我这一整轮“毛坯房装修踩坑”记录下来的全过程复盘，包含我踩过的每一个坑、总结出来的控场手段，以及一套可以直接抄作业的验收清单，给所有打算把项目从零交给 pi agent 的人一个参考。
1. 请 pi agent 之前，先搞清楚它到底是个什么装修队
很多人的第一反应是：pi agent 不是个编程工具吗？哪来“装修队”这一说。但你看它实际干活的形态，和一支施工队简直没有区别——给它一个项目仓库，它就往里钻，写文件、改代码、跑命令行、看报错、再修，全程自动化。工具形态上，它既有官网的 Web 界面，也有 CLI 和 IDE 插件，无论走哪条路，干的都是同一件事：把一个描述性的需求，翻译成真实可运行的代码改动。
1.1 从毛坯房到拎包入住，pi agent 到底能替你干哪些活
先说我实测下来它擅长什么。最基础的是单文件生成，比如“帮我写一个解析 JSON 的 Python 工具类”，这种它闭着眼写。再往上一个台阶，是多文件联动开发：新建一个 Flask 服务，同时补上配置文件、依赖清单、启动脚本和 README，这种跨文件的编排正是 agent 类工具的强项，因为它不是简单地补全代码，而是会先规划一遍目录结构，再按部就班地落盘。到了第三个台阶，它还能自己去跑命令、读报错、接着修——我遇到过一次场景，让它写一个数据库迁移脚本，它生成后自己执行了一遍，发现语法报错，回头改了再跑，最终把整个流程走通。
听起来很全能对不对？但这就是问题所在——全能施工队的另一面，是全靠你给方向和约束。它不会像有经验的项目经理那样主动问你“这面墙能不能敲”“这块地基承重够不够”，你给的需求模糊，它就自由发挥；你给的约束严格，它才按规矩办事。这和毛坯房装修一模一样：你告诉施工队“这里做个客厅”，他们可以给你刷白墙装吸顶灯，也可以给你搞出悬浮吊顶加无主灯设计，两种都是“客厅”，但你想要的到底是哪一种，取决于你说得多具体。
1.2 装修队的脾气：它很努力，但不会替你思考
我第一周用 pi agent 时最大的错觉，是把它当成了项目负责人。后来被坑了几次才意识到，它的工作模式更像一个“有执行力但没有审美的施工班长”：给它一张模糊的设计图，它能干出活来，而且干得很投入、很快，问题是它判断不了这个设计合不合理，也意识不到“这面墙承重墙不能砸”。
举一个最典型的例子。我让它“优化一下登录接口的代码结构”，它的回应是把原本三十行的函数重构成了五个模块外加一个自定义装饰器，还引入了一个事件发布机制。从代码规范角度看，这可能是教科书级的写法，但对我那个只有两个调用方的内部工具来说，这就是把一个简单的卫生间装修成了五星级酒店卫浴——好看，但根本没有必要，还凭空多出一堆以后要维护的工程量。
更麻烦的一点是，pi agent 有上下文窗口的限制。它不像一个真正的施工队可以长期驻场，它的“记忆”是有限的。聊了五十轮之后你再问它最初定的技术栈是什么，它可能已经忘得差不多，还会很笃定地按自己新生成的思路往下写。这种“善意的失忆”，比直接报错可怕得多——报错至少是明面上的，失忆是悄无声息跑偏的。后面我会专门讲怎么用项目内文档对抗这个问题。
2. 量房与设计图：开工前花一周想清楚，后面省十倍的返工
装修过的人都知道，最省钱的办法不是盯着师傅干活，而是设计阶段把所有细节定死。插座位置、瓷砖规格、柜子深度，有一项没定，施工队就按默认方案做，做完你不满意拆了重来，材料和工钱全打水漂。把 pi agent 用在代码项目上，这个逻辑完全成立——前期需求设计做得越细，后期返工越少。我第一回就是跳过了这个阶段直接让它开工，结果踩了个大坑。
2.1 先写“设计需求书”，而不是上来就赶工
我第一次用 pi agent 建项目时，只丢了一句话：“给我搭一个带用户管理的博客后端。”听起来信息量挺足对吧？结果它给我搭出来一个微服务架构：单独的 auth 服务、user 服务、post 服务，外加一层 API 网关，每个服务各配一套 Dockerfile。我打开目录结构时整个人是懵的——我要的只是一个单体应用，它给我整了一个互联网大厂的中台雏形。
这就是需求含糊的代价。pi agent 不是读心术专家，你只给“博客后端”四个字，它就会把训练数据里见过的大项目骨架套用过来，因为它学到的“专业做法”就是这样。所以我现在养成了一个习惯：任何项目开工前，先写一份需求书再让它动手。这份需求书不需要多长，但关键信息必须齐：
- 项目目标：这个项目要解决什么问题，服务对象是谁，核心使用场景是什么
- 功能边界：哪些功能必须做，哪些功能明确不做，哪些功能可以后置
- 技术栈指定：语言、框架、数据库、ORM、鉴权方案全部指定，不给自由发挥空间
- 验收标准：什么叫“装修完成”，以一串可执行的行为标准描述，比如“用户注册后能收到邮件验证链接，点击后账号激活”
- 禁止事项：明确告知哪些不要做，比如“不要引入消息队列”“不要拆微服务”“不许动前端目录”
写这份需求书的过程，本质上就是装修里的量房和画设计图。你越早把这些决定想清楚，后面 agent 跑偏的可能就越小。我的实测数据是：花费一天写的需求书，能省下后面至少三到四天的返工时间，非常划算。
2.2 把大目标拆成“阶段验收节点”，每个节点都要有活物
毛坯房装修不可能一次完工——拆改、水电、木工、瓦工、油漆、安装、软装，每一步做完都得验收，验证没问题才进入下一道工序。哪怕再急，也不会有人让油漆工在刚砌完的墙上直接刷。但我在用 pi agent 时，第一回就犯了按“大目标一次性交付”的错误：让它一次性把整个博客系统写完再给我看，结果等它交付时，我面对的是一大坨跑不起来的代码，报错信息层层嵌套，连问题出在哪个模块都得排查半天。
后来我改成了阶段式推进，效果立竿见影。具体做法是：把整个项目拆成几个有明确产物的小阶段，每个阶段跑完都让 pi agent 停下来，先演示、先测试、先验收，再进入下一阶段。以博客系统为例，我的拆法是：
- 阶段一：搭建项目骨架。数据库连接、配置文件、项目结构立起来，跑一个健康检查接口，能返回 200 就算验收通过
- 阶段二：实现用户注册和登录。做完之后我要在浏览器里真实注册一个账号试一遍，能注册、能登录、能退出才算过
- 阶段三：实现文章 CRUD。每篇文章能创建、编辑、删除，权限控制只允许作者本人操作
- 阶段四：打磨展示层。页面样式、分页、评论等非核心功能
- 阶段五：整体回归。跑一遍完整用户流程，补测试用例，修边角问题
这样拆的最大好处是问题被限制在一个小范围内。某个阶段跑不通，我能确定就是这一块的事，不会出现“改了个登录 bug，结果调用链深处某个服务跟着崩了”这种需要跨文件追踪的恐怖场景。
2.3 定好技术栈，别让它自由发挥
关于技术栈，我有一句实在话：除非你本人对技术选型毫无倾向，否则绝对不要把这个决定权交给 pi agent。它不是根据你项目的真实规模选择最合适的方案，而是根据自己训练数据里的“主流实践”来选。它默认的选择往往是大而全、重而稳的方案，因为它学到的优秀案例就是这么写的。
我踩过的一个具体坑是：一个内部报表工具，数据量就是几千行，我原本计划直接用 SQLite 加一个轻量导出功能就完事。结果 pi agent 用了 PostgreSQL，配了一套完善的迁移机制，还接入了 Redis 做缓存。我追问原因，它的回答是“考虑到后续扩展性和并发性能”。大哥，我一个内部工具，同时在线人数不超过十个人，你跟我谈并发性能，这不是装修队非要把杂物间做成影音室吗。
所以技术栈必须你亲自定死，而且要定到具体版本。我现在的需求书模板里会写明“Python 3.11 + FastAPI + SQLAlchemy 2.0 + SQLite”“前端使用 Vue 3 单页应用，不引入 UI 组件库”。版本定死也很重要，因为 pi agent 的训练数据里混着不同时期的代码，不定死版本它可能给你生成旧版 API 的调用方式，等运行时才发现对不上。
3. 水电改造阶段：架构搭建期最容易失控的环节
装修行业有句话叫“水电做不好，全屋白搞”。代码项目里最像水电改造的，就是起步阶段搭架构——目录结构规划、核心模块划分、数据模型设计、接口约定。这些一旦定错，后面所有代码都在错误地基上叠加，改造成本极高。而这一阶段恰恰是 pi agent 最容易失控的时刻。
3.1 它最兴奋的时候，就是最爱过度设计的时候
我观察到一个规律：pi agent 在架构搭建阶段会表现出一种奇特的“创作欲”。你让它搭个服务的骨架，它不满足于只是把框架立起来，非要加配置管理模块、统一异常处理、日志采集、中间件包一层又一层。这些设计单独看都很专业，但叠加在一个小项目上就变成了灾难——代码量翻倍、调试链路变长、真正出问题时你甚至不知道错误来自框架封装还是业务逻辑。
我印象最深的一次是让它搭一个简单的 API 服务，它自动生成了一套插件系统，支持自定义中间件注册，还写了一个“扩展点”机制。项目总共只有三个接口，我为这套插件系统花了一整天理解它的设计意图。后来我把这套东西全删了，亲手改成了二十行的普通代码，功能完全一样，但谁都能看懂。这件事给我的教训是：pi agent 的过度设计不是它笨，恰恰是它“太聪明”了——它在模仿优秀开源项目的风格，只是没意识到项目规模和复杂度根本不匹配。
3.2 控场手段一：单次任务范围严格限定
对抗过度设计最有效的办法，不是每次都在需求书里反复强调“不要过度设计”——实测下来这种抽象警告效果有限——而是把单次任务的物理范围锁死。我现在跟 pi agent 的交互里有一句高频指令：“本次任务只允许修改src/api/目录下的文件，不允许新建模块，不允许改变现有目录结构。”这句话的约束力比一整段“保持简单”的说明都强。
它的原理其实很好理解：pi agent 的规划机制是先看到一个目标，再拆解成修改动作。当修改范围被锁死在某个目录时，它的“创作力”就没地方施展了，只能在不新建文件、不新增模块的前提下完成任务。有一次我让它实现一个 CSV 导出功能，锁定了只允许改utils/export.py，它最后确实只是在这个文件里加了两个函数，没有顺手建一个export_service/包。这种明确的空间限制，比笼统的风格要求可靠得多。
3.3 控场手段二：先交计划，再动手干活
在架构阶段，我还有一个强制要求：“任何涉及项目结构变更的任务，先给我输出一份详细的执行计划，我确认以后你再动手。”这里有个技巧——不是让它输出“我打算怎么做”这种模糊描述，而是要求它列出每一步的具体动作：创建哪些文件、每个文件里大概放什么内容、是否会修改已有的哪个文件的哪部分、依赖关系是什么。
为什么这个手段有效？因为 pi agent 一旦进入“连续行动”模式，就会像上了头的装修队一样一路干下去，中间不会停下来反思方向。而让它先写计划，相当于在水电开槽之前先交一份线路图给你审。你看线路图发现它要在承重墙上开横槽，这时候拦下来只需要动动嘴；等它真的开完槽了你再拦，补墙的成本可就高了。
我实测过这个模式的效率影响：虽然有“先计划”这个额外步骤，但整体耗时反而下降了，因为计划阶段就拦掉了大部分错误方向，agent 在错误方向上的无用功少了，整个流程顺畅很多。
3.4 上下文是有限的：它真的会“忘掉”你最早的约定
这是我和 pi agent 长期协作后踩到最隐蔽的一个坑。有一次项目已经进行到收尾阶段，我让它给某个接口加个字段。它改完接口后，顺手把另一个模块里一段无关的逻辑“优化”了——因为它在对话早期“记得”我提过那模块有点问题。问题是，它记不完整，只记住了模糊的印象，下手时又改错了方向。
这件事让我意识到：对话越长，agent 越可能把注意力从最初的目标上漂移。它不像人那样心里有一份“项目底线清单”，任何时刻它的注意力都完全被最近的对话上下文占据。对抗这个问题的办法，是我后来在项目根目录加了一个AGENT_RULES.md文件，里面写着项目所有不可触碰的边界：哪些目录不许动、哪些设计决策是已经定死的、当前阶段在做什么、禁止引入哪些依赖。每次让 pi agent 干活前，我先追一句“先读AGENT_RULES.md，严格遵守里面的约束”。
这个文件就像一个写在墙上的施工管理条例，每次开工前让工人都读一遍。虽然折腾一点，但真的比反复在对话里强调有效得多，因为它的内容不会因为上下文滚动而被冲掉。
4. 泥木与油漆：功能迭代阶段的经典翻车现场
装修进入泥木阶段，意味着主体结构已经定了，剩下的是贴砖、刷漆这些“看着细但返工很要命”的活儿。对应到用 pi agent 开发，就是架构搭好之后的功能迭代阶段——加功能、修 bug、调样式。这一阶段看着是常规操作，实际上翻车率极高，而且翻车方式特别有“AI 特色”。我把最常见的四种翻车现场整理出来，每一条都是我拿真金白银的调试时间换来的。
4.1 幻觉依赖：它会把一个根本不存在的库写得像真的
如果你让 pi agent 写一段代码，它大概率会按训练数据里的记忆去引第三方依赖。问题在于，这个“记忆”有时候是幻觉——它会引用一个看起来名字正常、文档风格正常、但实际上根本不存在的 Python 包。
我遇到过一次：它在一个数据处理脚本里用了import dataproj，然后自动在requirements.txt里加了dataproj==2.1.0，接着还写了初始化代码dataproj.initialize(api_key=...)。我一看这名字，心想这什么库我以前咋没见过，去 PyPI 一查，根本没有这个包。它的整个调用链都建立在一个虚构的依赖之上，跑起来必然报ModuleNotFoundError。
这个坑的关键不是“它偶尔会瞎编库名”，而是它瞎编的时候会把周边配套都写得很完整，让你产生“这八成是个我没听过的小众库”的错觉。防范的办法很简单：每次它新增了依赖，不要直接照单收下，先在官方源里确认这个库存在且版本真实。安装完成后第一时间跑一遍 import，别把检查拖到后面。这点和装修里验收建材一个道理——瓷砖进场要先验货，不能用完之后才发现货不对板。
4.2 版本与 API 漂移：它脑中的示例代码永远是“某个时代的”
第二个高频翻车点是 API 版本漂移。pi agent 的训练数据里混着各个时期的代码，它对某些库的调用方式停留在它学的最多的那个版本，而这个版本通常不是最新版。我吃过最典型的亏是在某个前端项目里，它按旧习惯用了某 UI 库的全局注册方式，而当时该库已经更新到只支持按需引入。它写出来的代码从读的角度毫无问题，一跑就报错，搜索整个项目也找不到问题出在哪。
处理这个问题的思路要稳：不要试图让 pi agent 记住最新 API，它的知识有截止时间是物理规律。你要做的是把“以实测为准”立成铁律——凡涉及第三方库调用的代码，必须实际跑一遍验证；生成代码后第一轮就跑测试和构建，让报错来“纠偏”。你甚至可以主动在需求书里写一句：“如果发现我指定的库版本与你记住的用法不一致，以执行报错为准，不要猜测正确写法，直接查本地安装包的签名或文档。”
我自己的经验是，让 pi agent 自己去看它生成的代码能不能跑、报错是什么、然后根据真实报错调整，它最终能写出正确代码。这个过程不需要人类干预太多，但要把它从“凭记忆写代码”的模式切换到“看着真实环境反馈改代码”的模式。装完的水龙头能不能出水，要开了才知道，不能听师傅拍胸脯。
4.3 改了 A 坏了 B：它没有“全局记忆”，只会埋头干活
功能迭代阶段最让人血压升高的翻车，是修一个 bug 把另一个正常功能改坏。有过一次经历：我让它修一个日期格式化问题，它改完那个函数后，顺手把同一个文件里另一个完全无关的工具函数也重构了。我当时没有仔细看 diff，直接合并了。第二天用户反映某个导出功能的数据全乱套了，一查才发现是那个“顺手重构”改坏了格式逻辑。
这个坑的根源是 pi agent 在同一文件内改动时，容易“顺手”把附近的代码一并调整，它认为这是在优化，但实际上超出了你的指令范围。我现在的对策是双管齐下：第一，重要改动前后都建 git 检查点，动手前先 commit 一个稳定版本，这样无论 agent 改坏什么，一条git checkout就能回到安全状态。第二，每次 agent 完成任务后，我强制自己过一遍git diff，并且只关注“和需求相关的改动”。所有跟任务无关的变更，一律要求它还原。这个操作看起来很基础，但确实挡下了至少一半的“顺手改坏”事故。
4.4 规则说硬话：负面清单越具体，它越乖
在迭代阶段，我发现一个有意思的现象：pi agent 对“负面指令”的遵循程度，远比“正面期望”高得多。你跟它说“代码要保持简洁”，它可能当耳旁风；但你说“禁止创建src/utils以外的工具文件”，它基本都会遵守。这是因为负面清单的内容是可以机械校验的，agent 可以在行动前明确判断某动作是否触碰红线，而正面期望比如“简洁”是模糊的，它不知道具体到什么程度算达标。
所以我把项目里所有“不要做”的条款都写成可直接查验的硬规则。举几个实际用过的条目：
- 禁止在
pages/目录之外创建任何新文件 - 禁止修改
models.py中已有字段的名称 - 禁止在没有明确指令的情况下升级已有依赖的版本
- 禁止在代码中新增全局单例对象
这种清单越多越细，agent 的自由发挥空间越小，翻车概率就越低。你甚至可以尝试在它开始干活之前要求它“复述一遍本次改动涉及的负面清单”，如果它复述得不对，先纠正再开工，能省掉后续一堆麻烦。
5. 竣工验收：agent 交房之前，你至少要做的三件事
装修队撤场不等于可以入住。验房是收楼前最不能省的环节，墙面空鼓、地漏堵不堵、门窗顺不顺，每一项都要亲自过。用 pi agent 开发的“交房验收”同样不能省，你不能因为它跑完了一遍测试就说“行了”。有几件事是我从第一轮踩坑后一直坚持做的，写下来你们直接照着抄。
5.1 第一件事：跑一遍“入住演练”——端到端走真实用户路径
单元测试过了不代表功能能用，这两个结论之间的距离可能比想象中大得多。我第一回让 pi agent 交付一个带登录和列表查询的系统时，所有测试都绿，但我自己打开浏览器一操作就懵了：注册成功之后跳不到登录页，表单提交按钮没有点击反馈，列表接口在鉴权模式下超时。这些全是在“满足接口规格”的测试里发现不了的问题。
竣工验收的标配动作，是手动把一条完整用户路径走一遍。以用户系统为例，路径是“注册 → 收邮件 → 点链接激活 → 登录 → 访问受保护页面 → 退出登录 → 再登录”。这条路径上的每一步都必须真实操作，不允许用模拟器或 mock 替代。pi agent 能帮你写代码，但“像个真人用户一样把流程跑通”这个验收动作，必须由你做。你在流程里感到任何一点点不对劲，都要当成验收不合格处理，追着 agent 改到顺畅为止——这就是装修验房时在房间里走了无数遍检查插座开关有没有电的动作，省不得。
5.2 第二件事：每个文件都要有存在的理由，解释不清就删
交付完成后，我还会做一轮“删减验收”。具体操作是：要求 pi agent 对项目里每一个文件做一次自我介绍——这个文件的作用是什么，被谁调用，没有它会怎样。对它解释不清或者解释得很牵强的部分，我会直接删掉然后跑测试。
这个做法源自一次惨痛经历。项目里有个utils/helpers.py文件，我问它这个文件是干什么的，它支支吾吾说是“提供一些通用辅助函数”。我追问“具体是哪些函数，哪里用到了”，结果发现文件里大部分函数在整个项目里没有任何调用，是它早期“顺手”写的，体积倒是很可观，全是死代码。我删掉这个文件后，全项目测试照常通过，还顺手少了上百行要维护的代码——装修里这就是那块贴着漂亮墙纸但里面早就空心的隔断墙，看着没什么，留着才是隐患。
5.3 第三件事：把核心路径固化成自动化测试，防止它下次装修拆墙
最后一项验收动作，是把那条用户核心路径写成自动化测试，固化下来。为什么这件事要在验收阶段做？因为我发现 pi agent 在后续迭代中最大的隐患不是能力，而是“回归”——它有超过五成的概率在一次后续修改中把之前已经修好的功能再弄坏。自动化测试是你唯一的低成本防线，相当于装修完成后拍了一整套房屋结构照片存档，下次谁想拆墙，你先翻照片看看这面墙里有没有管线。
哪怕你的项目很小，我建议至少把这几条写成测试：
- 最核心的业务路径（用户注册 → 登录 → 完成一次核心操作）
- 最容易回归的边界逻辑（权限校验、空值处理、异常分支）
- 外部依赖变更时的烟雾测试（比如第三方接口是否可达）
实测下来，花半天时间把这些测试写掉，相当于给项目上了一道保险。后来的每次迭代我都是让 agent 先跑一遍全量测试再动手，改完再跑一遍，哪次红了立刻定位到具体行为，效率比靠肉眼盯 diff 高得多。
6. 装修公司没告诉你的事：我对 pi agent 的最终使用心得
经过一整轮“毛坯房装修”，我对 pi agent 的定位终于清醒了。它确实是个很能干的施工队，但不是什么项目兜底方案。网上不少夸大的宣传把它说成“一句话帮你做出一个完整产品”，我的实测结论是：一句话你能得到的只有一堆不靠谱的毛坯——格局看不清，材料不确定，水电图全是套路，最后还需要你亲自精装。
6.1 它省掉的是打字和琐碎执行，不是思考和决策
这个结论是我踩完所有坑之后最想分享的一条。pi agent 把“从需求到代码”的翻译成本压缩到了极低，但它解决不了“这个需求到底对不对”的问题。你的项目要不要做、做成什么样、技术选型怎么定、哪些边界必须优先处理、哪些功能可以砍掉——这些决策责任从头到尾都在你身上。它不是一个有经验的装修总监，它更像一支什么活儿都能接但需要你盯在工地的施工队：你不盯着，它就按自己的喜好发挥；你盯得紧，它能把活干得又快又利索。
6.2 效率提升是真的，但省下的时间要重新分配
如果把整个项目的总工时算下来，我用 pi agent 并没有比传统开发方式省下多少时间，至少第一轮是这样。但重点在于时间结构变了：原来大量的时间花在写代码、修语法错误、查文档、配环境这些“搬砖活”上，现在这部分压缩了很多，省出来的时间我全部填到了需求设计、代码审查和测试验收上。这个时间重分配的价值非常大，因为搬砖活的改进空间有限，而需求设计和验收质量的提升是杠杆性的——前期想得越透，后期返工越少，项目质量上限高了一大截。
6.3 给第一次请装修队的你，一份不踩坑清单
最后，把这一整轮的经验浓缩成一份可以直接照做的清单，送给第一次准备把项目从零交给 pi agent 的人：
- 开工前写好需求书：目标、边界、技术栈、验收标准、负面清单缺一不可
- 把项目拆成阶段节点，每个节点交付可运行产物，验收通过再进下一阶段
- 凡涉及结构变更的任务，先让 agent 交执行计划，你确认后再动手
- 在项目根目录放
AGENT_RULES.md，把不可触碰的边界写成硬规则，每次开工前要求它读 - 它新增依赖先验证存在性和真实版本，装完立刻 import 测一遍
- 重要改动前先 git commit 建立检查点，交付后仔细过
git diff，无关改动一律打回 - 不轻信测试绿灯，自己按真实用户路径完整跑一遍验收
- 让 agent 解释每个文件的存在理由，解释不清就删
- 把核心路径固化成自动化测试，做后续迭代的回归防线
- 始终记得：决策者是你，它是施工队，别把这个位置搞反
按这份清单操作下来，pi agent 仍然会时不时给你整出点惊喜，但不会有那种让你想把电脑合上冷静三天的惊吓。毛坯房装修踩坑不可怕，可怕的是踩过坑还不知道坑在哪。希望这篇复盘能让你少踩几个。
