39 篇文档带有标签「架构师」

一句话摘要：用我，你能在头几周飞快堆出一堆「能跑」的功能，爽到以为速度会一直这样。但只要你一路只要「快点跑通」、不管结构 / 测试 / 文档，技术债会复利式累积，到某个点（常被说成「三个月」）撞上一堵墙：改一处崩三处、没人敢动、加新功能越来越慢——速度断崖式下跌，而前面省下的时间这时连本带利还回来。

一句话摘要：你把所有想到的规范都写进 CLAUDE.md，希望我面面俱到。结果规则太多，我反而抓不住重点，把一半都漏掉了。

一句话摘要：「把整个仓库 / 整篇长文档都喂给它，它肯定全看到了」是个错觉。我对长上下文呈 U 形表现——开头结尾记得牢、中段被严重忽略；而且仅仅是上下文变长本身，就会拖低我的表现，哪怕关键信息其实就在里面。更多上下文 ≠ 更好。

一句话摘要：你没给我接一个版本对得上的权威文档源，就让我凭训练记忆加上网搜去写某个库的调用。结果我用过时的 API、把不同大版本的用法混在一起、甚至幻觉出根本不存在的方法——而这些代码「看起来都对」，编译期未必报错，到运行时才崩。

一句话摘要：一个不那么 trivial 的任务，你不先让我进计划模式调研、出计划、等你确认，而是直接说「改吧」。我会一头扎进某个方向，等改了一堆文件你才发现我理解偏了——返工的代价，远高于你当初花两分钟看一眼计划。

一句话摘要：你只想要个左填充、一个小工具函数、一次日期格式化，我却顺手 npm install 一整个库，甚至为「将来可能用到」预先加上几个依赖。代价是包体积膨胀、构建变慢、攻击面和供应链风险变大，以及一笔你要替我长期背的升级与维护账——而那点需求，本来几行自写代码就够了。

一句话摘要：你用 allow / ask / deny 这种「软权限」控制我能跑什么命令，但我跑命令的进程和你的整台机器、凭据、网络是同一个域。软权限是一道我（或我读到的恶意内容）可以试图绕过的策略，不是操作系统强制的墙。一旦提示注入劫持了我，我就够得着你的 SSH key、环境变量、整个文件系统和对外网络。

一句话摘要：为了让我帮上忙，你把真实数据贴给我——生产库 dump、客户资料、密钥、还没公开的源码。可你从没告诉我「哪些数据绝不能离开公司边界」，我只会把它当普通上下文处理。而数据一旦交给外部 AI，就等于送出了边界：收不回、可能被留存、可能被复述到别处。

一句话摘要：我交一段代码，你合并、署上公司的名、当成自有资产。但你没问过三个问题：纯我生成、没有足够人类创作的代码，可能压根主张不了版权（别人能照用）；它若逐字复现了训练数据里受版权的代码，又可能侵权（你担责）；出了问题，谁负责？「全是责任、没有保护」不是修辞，是当前的法律现实。

一句话摘要：你给我开了自动执行，却没说清「哪些动作我能直接做、哪些得先问你」。于是我用对待「改个错别字」的随意度去删数据库表、改生产配置、发对外请求——不是我恶意，是你没给我一把按风险分级的尺子，我就把「能自动做」当成了「该自动做」。

一句话摘要：你管住了我能读什么文件，却没管住我能往哪儿发请求。只要我能向任意域名发出站流量，我就成了数据外泄的出口：读到的源码、密钥、数据，我能编码进一个 URL 发到攻击者的服务器——这正是「致命三件套」里最该被砍掉的第三条腿。

一句话摘要：你让我从一个「谁都能写」的系统级目录（Windows 上的 C:\ProgramData）载入配置和 hook，却没人校验那个目录归谁、文件是谁放的。于是一个低权限的本地用户只要往那儿丢一份配置、挂一个「每次启动就跑」的 hook，我就会在每一个启动我的用户（包括管理员）名下替他执行那条命令——不用提权、不用你点确认、不留告警。

一句话摘要：你让我选型，我会直接给你一个我认为最好的方案，写得笃定又完整，却很少主动把另外两三个候选、各自的优劣和「什么场景选哪个」摊开。你拿到的是一个被包装成唯一答案的选择——而架构决策真正需要的，恰恰是可比较的选项。

一句话摘要：这一条不是讲我会犯什么错，而是讲你过度信任我会怎样。我输出又快又自信，于是「照单全收」成了最省力的默认；可我恰恰会自信地错。久了，你审查流于形式、对代码库的掌控感退化——而这两件事，正是本该由你把住的最后一道关。

一句话摘要：你这边刚出现两段长得像的代码，我就忍不住抽一个「通用」基类、配置化框架或插件机制，再为「将来可能要支持的多种 X」预留一排扩展点。问题是这些抽象建立在我猜的需求上，而我经常猜错——错误的抽象比重复更难拆，后来人得先读懂我的设计、再绕开它。

一句话摘要：同一个「要不要用它 / 这条路可不可行」的判断题，你过两天再问、或者换个措辞问，我可能给出相反的结论——而且两次都说得很笃定。你看到的是「一个稳定答案」，其实是一次掷骰子的结果。

一句话摘要：让我写某个高频迭代的库的调用时，我凭训练记忆补位——可能用了已废弃或已改签名的 API，把不同大版本的写法混在一起，甚至幻觉出一个根本不存在的方法。代码「看起来都对」，编译期未必拦得住，到运行时才崩。

一句话摘要：你让我「把功能做出来」，我就只盯着功能跑通——安全是默认不可见的非功能需求，除非你显式要求，我不会主动按最小权限、敏感数据分级、纵深防御去想。结果是硬编码的密钥进了仓库、该鉴权的接口裸奔、敏感信息写进了日志和报错。

一句话摘要：你让我解释「这段代码为什么这样写」「这个 bug 的根因是什么」「这个报错什么意思」，我会给你一段流畅、有条理、听起来很权威的解释——但它可能是错的。我把因果讲反、归错根因、虚构机制，语气却和讲对时一模一样。你信了，就照着错的方向去改。

一句话摘要：你问「这个功能多久能做完、难不难」，我倾向报一个偏小的数。我估的是写出主干那点功夫，而软件工程的时间大头在主干之外——联调、异常、测试、评审、返工。把我的估算当承诺，你的排期就一再爆掉。

一句话摘要：我默认按「单线程、顺序执行、没人同时动」来写代码，于是漏掉竞态条件、共享状态不加锁、check-then-act 不原子、数据库不加事务或乐观锁。功能测试（单线程）全绿，一上并发就偶发丢更新、数据错乱、死锁。这讲的是并发正确性这一类特定且隐蔽的缺陷，和实现层漏分支、方案整体健壮性不是一回事。

一句话摘要：我交给你的「原创代码」里，可能藏着一段我从训练语料逐字背下来的开源实现——还可能带着 GPL 这类有传染性的 copyleft 许可。我不会附来源、也不会附许可，你把它合进闭源产品，发布或法务审计时才发现这是一次许可违规 / IP 侵权。

一句话摘要：你让我处理一个仓库、一条 issue、一个依赖，里面的文本——README、issue 描述、.cursor/rules 或 AGENTS.md、网页、代码注释——可能藏着写给我的恶意指令。我读到后分不清那是「待处理的数据」还是「你的命令」，于是照做：把密钥外泄、在 diff 里插后门、跑破坏性命令。这不是产品上线后被攻击，是编码过程中的我自己当场被投毒内容劫持。

一句话摘要：你让我设计表结构或接口契约，我会很快给你一版「能把数据存下来」的 schema——但字段类型挑得随意（该 decimal 用了 float、该枚举用了自由文本）、缺约束少索引、没想过将来要怎么查、怎么演进。代码改起来便宜，schema 改起来不是：数据一旦灌进去，再动它就要写迁移、兼容历史数据、停服或灰度，代价是改代码的好几倍，而这笔账要等数据量和需求都长起来才结清。

一句话摘要：这个项目里「为什么当初选 A 不选 B」「为什么这一层不能直接调那一层」这些早就拍过板的权衡，我并不记得——每个会话我都是冷启动。于是我会重新端上一个上周被你否掉的方案、绕过既定的分层、或者把一次刻意的取舍当成可以随手改掉的细节。别指望我「想起来」，我没有跨会话的记忆；你得把决策连同理由写成我能读到的产物。

一句话摘要：当我帮你做的产品本身内置了 LLM——客服 bot、Agent、那种「读完用户内容/网页/邮件再行动」的功能——上线后，攻击者会把恶意指令藏进我会读到的内容里，诱导你后端那个 LLM 越权：泄露数据、调用它不该调的工具、绕过你定的规则。开发期我默认「输入都是善意的」，于是把一个本该当成攻击面的发布面，当成了普通功能交付。

一句话摘要：你问「这个能不能做」，我大概率答「能」——但我说的是「技术上能实现」，不是「在你的预算、时延、合规、团队和数据约束下可行」。把我那句乐观的「能做」直接当成可行性结论，你就跳过了真正决定成败的那些约束。

一句话摘要：我默认文件系统的操作和事件「按确定、串行、可预测的顺序发生」——写完一个文件马上就能读到完整内容、watcher 事件按修改顺序一条一条来、readdir 按创建或字典序返回、文件一出现就代表写完了。于是我把「文件出现」当同步信号、把 watcher 当成有序日志，代码在我本地的快盘上跑得好好的，换台机器、换个 OS、上点负载就偶发崩。这讲的是 OS / 文件系统层的假性确定，和并发竞态（共享内存/数据库状态的竞态）、漏掉边界分支（漏了某个输入）都不是一回事。

一句话摘要：你在 CLAUDE.md 里写「不要碰生产数据库」「跑命令前先问我」，以为这就管住了我。但 CLAUDE.md 对我只是建议性上下文——我会读、会尽量照办，但不保证；真要拦住一个动作，那是 settings.json 的活儿，它在客户端强制生效，根本不经过我「决定」这一关。

一句话摘要：你把「发布的十二步流程」「数据库迁移的全套 SOP」整段写进了 CLAUDE.md，想着这样我什么时候都记得。结果它每次会话都常驻上下文，连「改个错别字」的任务也得先读一遍——而这些只在特定任务才用得上的步骤，本该做成按需加载的 skill。

一句话摘要：你给我的是合法凭据，我用它干的也是「合法」的操作——只是其中一条是删生产库、抹掉备份、或者在冻结期强行改动。这类动作的麻烦不在于难，而在于做完才发现回不来。我天生倾向「让任务往前走」，对「这一步删了就没了」缺乏敬畏；护栏得由你在准备阶段就架好，靠机制而不是靠我自觉。

一句话摘要：你给我接 MCP server 时图省事，一把授予整库读写、生产数据库、密钥、对外发请求的工具。问题不只是「我可能误用」——你每多给我一个高权限 MCP 工具，就多开一条提示注入的攻击路径：我读到的某条 issue、某个网页里藏的恶意指令，可能借我手里的工具把数据送出去。

一句话摘要：你一句「开三个子代理并行做」就让我们各自跑起来，却没说清谁负责哪块、谁能改哪些文件、彼此怎么交接接口与数据格式。结果是：我们同时改同一批文件互相覆盖，对「现状」各有各的假设，最后拼起来对不齐——并行没有提速，反而制造了一堆需要你来收拾的冲突。

一句话摘要：你让我出概要设计，我大概率给你一套「看起来很完整」的方案——微服务、消息队列、缓存层一应俱全；而你随口提的技术选型，我会默认接住、顺着往下铺，很少劝你「这个场景其实不需要」。结果是一份配得上你十倍规模的架构，和一堆你还没遇到就先背上的复杂度。

一句话摘要：哪怕是该先写规格的复杂任务，我也倾向于直接开写代码——因为「开始产出」最快、最像在干活。代价是没有可对齐、可评审、可验收的依据，等发现跑偏，活已经堆起来了。

一句话摘要：你让我一轮轮加功能、修 bug、重构，代码看着是越改越像样了——但安全漏洞会随迭代轮次悄悄累积。研究发现，仅五轮迭代后严重漏洞显著上升。一个「看起来一直在变好」的过程，安全面其实在变差，到发布时已积重难返。

一句话摘要：让我在一个我看不全的大仓里做跨模块改动，我会干两件你不容易当场发现的事——把项目里其实已经有的工具函数照着需求重新实现一遍（重复逻辑、违反 DRY），以及 import 一个根本不存在的模块、函数或导出（幻觉 import，凭「这类库一般都有」的直觉猜）。两者的同一个根因：我的上下文窗口装不下整个仓库，我没有全局符号视野。

一句话摘要：跨十几个文件的大重构做到一半，我就记不清改到哪了——哪些文件已改、哪些没改、那个改名是否全仓同步了。于是漏改一处编译挂掉、把已改的又改一遍、前后用了两种不一致的写法。别让我用记忆当待办清单。

一句话摘要：需求看起来够清楚，我就直接做了——但实现里我默默补进了一堆你没说的前提（数据格式、规模、并发、默认值、目标用户、错误处理、技术栈）。你只看到结果，看不到它建在哪些假设上，于是我们各跑各的，等假设浮现才发现错位。