AI时代开发新思维：从代码洁癖到高效挖坑

1. 从“代码洁癖”到“挖坑人生”：一个老码农的认知转变

干了十几年开发，我发现自己身上有个特别拧巴的毛病：代码洁癖。这玩意儿听起来像个优点，对吧？追求优雅、整洁、可维护的代码，简直是工程师精神的体现。但这些年，尤其是AI编码智能体（比如Claude Code、Cursor这类工具）开始普及之后，我越来越觉得，过度的“洁癖”正在变成一种负担，甚至是一种阻碍。它让我在项目初期过度设计，在重构时犹豫不决，在面对快速变化的业务需求时显得笨拙。直到我开始尝试“挖坑”，或者说，有策略地、坦然地接受一些“技术债”，我的开发效率和项目节奏才真正顺畅起来。

我说的“挖坑”，不是指写一堆烂代码然后跑路。那叫不负责任。我指的是，在明确知道某个实现不够完美、存在已知局限、甚至未来可能需要重写的情况下，依然选择先把它做出来，让功能跑通，让业务先转起来。这是一种基于优先级和现实约束的主动选择。比如，为了赶一个核心功能的演示，你可能会先写一个内存缓存，而不是立刻去集成Redis；为了验证一个算法逻辑，你可能先写一个单线程版本，而不是上来就搞分布式。这些“坑”，是你亲手埋下的，你知道它们在哪，也知道未来某个时间点需要填上。这和你因为无知或懒惰写出的、自己都理不清的“屎山”，有本质区别。

为什么现在特别需要这种心态？因为开发的环境变了。以前，我们面对的需求、技术栈和协作模式相对稳定，有充足的时间去打磨一个“完美”的模块。但现在，业务迭代快如闪电，新技术（尤其是AI）层出不穷，你花两周精心设计的“优雅”架构，可能上线一周就因为业务方向调整而变得不合时宜。更重要的是，AI编码助手的出现，极大地降低了“填坑”的成本。以前让你头疼的重复性重构、边界条件处理、文档补充，现在可能只需要给AI一个清晰的指令。在这种背景下，过分执着于每一行代码的“洁净度”，就像在沙滩上用沙子雕刻城堡，却担心下一个浪花会弄湿你的作品——你错过了建造更大、更有趣东西的机会。

2. “代码洁癖”的具体表现与隐性成本

要放下洁癖，首先得看清它长什么样。在我身上，它曾经以多种形式出现，每一种都消耗着宝贵的时间和心力。

2.1 过度设计与过早优化

这是最典型的症状。接到一个需求，不是先想“最快实现路径是什么”，而是立刻陷入“如何设计才能应对未来所有可能的变化”。我会花大量时间画UML图，设计各种接口和抽象层，争论是用策略模式还是模板方法模式更“优雅”。一个简单的用户上传功能，我可能非要抽象出一个FileProcessor接口，下面再衍生出ImageProcessor、DocumentProcessor、VideoProcessor，并为每个处理器设计一套完整的责任链。结果呢？需求其实只要求传图片，而且未来三个月都没有处理视频的计划。等我真的把这套“完美”架构搭好，用简单脚本就能搞定功能的同事，早就开始做下一个需求了。

马丁·福勒在《重构》里说：“第一次做某件事时只管去做，第二次做类似的事情时会产生反感，但无论如何还是做了，第三次再做类似的事，你就应该重构了。” 洁癖患者的问题在于，在“第一次”的时候，就试图直接跳到“第三次”的完美状态。这种过度设计带来的隐性成本极高：它延迟了价值交付，增加了初始复杂度，并且由于未来充满不确定性，你精心设计的扩展点很可能永远用不上，或者用错了地方。

2.2 对“坏味道”的零容忍与中断式重构

Clean Code（代码整洁之道）教会我们识别代码的“坏味道”，比如过长函数、过大类、重复代码等。这本身是好事。但洁癖患者容易将其变成一种强迫症：一旦在代码审查或自己阅读时发现“坏味道”，就必须立刻停下手中的工作，优先进行重构，否则就浑身难受。

我曾经就因为看到一个300行的函数，尽管它工作正常且逻辑清晰（只是长了点），就硬生生打断了正在进行的特性开发，花了两小时把它拆分成五六个小函数。拆完之后，逻辑是更“整洁”了，但我原本要做的那个紧急需求却耽误了。更讽刺的是，一周后那个模块因为业务调整被整体重写，我那两小时的重构投入完全归零。这种“中断式重构”打乱了工作流，破坏了心流状态，其机会成本往往被严重低估。

2.3 在命名和格式上的无限纠结

“这个变量叫userData好还是userInfo好？”“这个方法是processPayment还是handlePayment更准确？”为了一个命名，能对着屏幕发呆十分钟。为了代码格式，能跟同事在PR评论里争论好几个来回：花括号是换行还是不换行？import语句应该按字母排序还是按模块分组？

这些细节重不重要？重要。统一的规范能提升可读性和维护性。但它们的收益是边际递减的。花10分钟把命名从80分提升到95分，可能值得；但再花30分钟纠结如何提升到99分，就很不划算了。尤其是在项目初期或快速原型阶段，这种纠结纯粹是内耗。现代IDE都有强大的重命名重构功能，linter和formatter（如Prettier、Black）可以自动处理大部分格式问题。把时间花在更需要人类智能判断的逻辑和架构上，才是更优选择。

2.4 对第三方代码或“非我族类”代码的本能排斥

有些洁癖开发者，对自己写的代码要求严格，对别人写的、尤其是风格不同的代码，容忍度极低。看到别人用了全局变量、看到遗留系统里复杂的条件嵌套，第一反应不是去理解其上下文和历史原因，而是“这代码太脏了，必须重写”。这种心态会导致团队协作时的摩擦，也让你难以有效维护和迭代既有系统。系统总是在演进的，纯粹的“绿地开发”少之又少，学会与“不完美”的代码共存并安全地修改它，是一项至关重要的能力。

3. 为何“挖坑”在AI时代成为一种高效策略？

理解了洁癖的成本，我们再来看看“挖坑”为什么在今天，特别是在AI工具的加持下，反而成了一种更聪明的策略。这里的核心逻辑是：价值交付速度 > 代码完美度，并且AI极大地降低了后续优化的成本。

3.1 加速验证与反馈循环

互联网产品开发的核心是验证假设。你的功能、你的商业模式，到底成不成立？用户买不买账？最快的验证方式就是做出一个“最简可行产品”（MVP）扔到市场上看反应。“挖坑”思维完美契合MVP理念：用可能有点“糙”但核心功能完整的代码，快速实现产品原型。

比如，你要做一个智能客服的意图识别模块。洁癖的做法可能是：先研究NLP模型选型（BERT还是GPT？），设计一个可插拔的模型管理框架，写好单元测试和集成测试，再考虑如何做A/B测试分流……一圈下来，两周过去了，你还没看到实际效果。“挖坑”的做法则是：直接用OpenAI的API（或Claude的API），写一个不到100行的函数，把用户问题发过去，解析返回的JSON，把意图分类结果存下来。这个函数可能没有重试机制、没有降级策略、没有缓存、计费也可能有问题——这些都是“坑”。但重要的是，你在一天内就让业务方看到了一个能跑起来的Demo，获得了第一批真实用户query，验证了技术路线的可行性。这个反馈的价值，远大于你写出一个“完美”但未经检验的框架。

3.2 AI是最高效的“填坑”伙伴

以前，“挖坑”容易，“填坑”难。你挖了个坑，意味着未来要自己花时间填上，这个“债”是实实在在的。但现在，情况变了。AI编码助手（如Claude Code、GitHub Copilot）在处理重复性、模式化、以及基于现有代码的优化任务上，效率惊人。

你之前为了赶时间，写了一个没有错误处理和日志的数据库查询函数？现在你可以对AI说：“为这个fetchUser函数添加完整的错误处理（包括连接失败、查询超时、无结果），并加上结构化日志。” AI几秒钟就能生成一个考虑周全的版本。你之前用了一个简单的数组在内存里做缓存，现在数据量大了需要换成Redis？你可以对AI说：“将当前的内存缓存逻辑（指给代码）替换为使用Redis的实现，键名设计为user:{id}，并设置TTL为1小时。” AI能帮你生成90%的样板代码。

这意味着，你“挖坑”的决策成本降低了。你可以更放心地为了速度而牺牲一部分代码质量，因为你知道，后续用AI来提升质量、填补缺失功能（如日志、监控、测试）的成本很低。你从“写代码的人”变成了“定义问题、验收结果的人”，AI负责执行那些繁琐的、需要耐心但创造性不高的“填坑”工作。

3.3 应对不确定性的最佳实践

业务需求和技术环境的不确定性是常态。你今天为“未来可能支持视频”而设计的复杂抽象，明天可能因为公司战略转向音频而完全作废。你今天精心挑选的“最新最酷”的技术栈，明年可能因为社区衰落而无人维护。

“挖坑”思维是一种务实的态度：承认自己无法预测所有未来，因此只解决当前确定的问题。用最简单的、耦合度最低的方式实现当前需求。当变化真的来临时，由于你的代码没有过度设计，反而更容易被修改或替换。如果那个“未来”一直没来，那你就省下了大量过度设计的精力。如果它来了，你也有了一个经过验证的核心逻辑和更清晰的新需求，这时再带着AI助手进行有针对性的重构或扩展，成功率更高，浪费更少。

4. 如何科学地“挖坑”：原则、边界与实操方法

“挖坑”不是乱写代码，它是一门有原则的技术。以下是基于我个人实践总结出的几条“挖坑”准则。

4.1 明确标注与债务管理

这是最重要的一条：你挖的坑，必须被明确标记出来。不能假装它不存在。

• 代码注释（TODO/FIXME/HACK）：这是最直接的方式。在代码中显式地留下标记。

  # TODO: 此处使用内存缓存，用户量超过1万后需替换为Redis。@owner:张三 @date:2023-10-27 # HACK: 因第三方API限制，此处用循环模拟批量请求，效率低下，需寻找替代方案。 # FIXME: 错误处理不完整，未考虑网络重试和降级策略。

  光写TODO不够，最好加上负责人（@owner）和创建日期（@date），方便后续追踪。许多IDE和代码扫描工具可以聚合展示这些标记。

• 项目管理工具跟进：将重要的“技术债”作为任务卡片（如Jira Issue, GitHub Issue）记录到项目管理工具中。明确其优先级、预估工时和关联的业务价值（例如，“将内存缓存改为Redis，预计提升QPS 50%，降低响应延迟30%”）。这样，“技术债”就从看不见的隐患，变成了可管理、可规划的工作项。

• 团队共识：在团队内建立共识：“挖坑”是允许的，甚至是鼓励的，但必须公开透明。在代码评审时，如果看到为了赶进度而引入的临时方案，评审重点不应是“这代码不优雅”，而应是“这个临时方案的边界条件是否清楚？有没有对应的TODO和Issue？会不会引入线上故障？”

4.2 控制“坑”的深度与影响范围

“挖坑”要挖“浅坑”，避免“深坑”，更要防止“坑连坑”形成“塌陷区”。

• 隔离与封装：将不完美的实现封装在特定的模块、类或函数内，并定义清晰的接口。这样，未来的修改只会影响这个封装单元，不会波及整个系统。例如，你把那个不完善的缓存逻辑封装在一个SimpleCache类里，未来换Redis，只需要修改这个类的内部实现，所有调用它的代码都无需改动。
• 避免核心路径挖坑：在系统的核心业务逻辑、数据一致性保障、安全认证等关键路径上，要极度谨慎。这些地方的“坑”容易导致严重故障。可以为了速度在辅助功能、非关键路径上“挖坑”，但核心链路必须保证健壮性。
• 设定明确的“填坑”触发条件：不要模糊地说“以后优化”。要定义清晰的指标。比如，“当日活用户达到5万时，启动数据库分库分表项目”；“当这个接口的95分位响应时间超过200ms时，优化其算法”。让数据驱动决策，而不是个人的感觉。

4.3 利用AI进行“坑”的预处理与快速填充

这是新时代“挖坑”策略的核心技能。你不是在制造混乱，而是在为AI创造明确的、可执行的任务。

• 在“挖坑”时就想好AI指令：当你写下# TODO: 优化这个排序算法，目前是O(n^2)时，你可以在心里或者注释里补充上对AI的提示：“优化目标：时间复杂度降至O(n log n)以下，保持稳定性，参考归并排序或快速排序实现。”
• 批量处理同类型“坑”：当你积累了多个需要添加日志、或错误处理的函数时，不要一个个改。你可以写一个清晰的提示给AI：“扫描本项目所有service目录下的.py文件，找到所有直接进行数据库查询（使用db.session或execute）的函数，为它们统一添加try-except块，记录错误日志，并在异常时返回友好的错误信息。” AI可以帮你一次性处理一大批类似问题。
• 用AI进行“坑”的评估：你不确定某个临时方案的风险有多大？可以把代码片段和上下文丢给Claude或ChatGPT，问它：“这段代码作为临时方案存在哪些潜在风险？最可能出问题的地方是哪里？如果要保持功能不变，最小化的加固措施是什么？” AI可以给你一个相当全面的风险评估清单，帮助你决定这个“坑”到底该不该挖，或者该怎么挖更安全。

5. 实战案例：从“洁癖设计”到“挖坑实现”的思维转换

让我们通过一个具体的场景，来看看两种思维模式下的不同做法。

场景：一个内容平台，需要新增“文章自动标签”功能。给定一篇文章的标题和正文，系统需要自动为其打上若干个标签（如“科技”、“金融”、“健康”）。

5.1 “代码洁癖”模式下的做法

1. 技术选型与设计：首先陷入漫长的技术调研。是直接用现有的云服务（如AWS Comprehend， Google Natural Language）？还是自己微调一个开源模型（如BERT）？各自成本、效果、可控性如何？开始画架构图，设计TaggingService抽象接口，下面可能有AwsTaggingImpl,BertTaggingImpl。考虑如何做模型的热更新、如何做A/B测试、如何设计降级策略（模型服务挂了怎么办？）。
2. 实现：花一周时间搭建框架，定义好所有接口和DTO（数据传输对象），编写模型调用客户端，集成配置中心，写好单元测试。
3. 结果：一周后，一个“优雅”的、可扩展的标签服务框架搭建好了，但还没有任何实际的标签生成能力。业务方来问进度，你只能说：“框架搭好了，正在集成模型。”

5.2 “挖坑”模式下的做法

1. 定义最简可行方案：目标是“最快让文章有标签”。评估后决定，直接用OpenAI的Chat Completion API是最快的。不需要训练模型，效果足够好，按量付费，初期成本可控。
2. 快速实现：新建一个tagging.py文件，写一个函数：

   import openai import os import json # HACK: 密钥硬编码，后续需移至环境变量或配置中心。 openai.api_key = "sk-xxx" def generate_tags_naive(title, content): """ 根据标题和内容生成标签。 TODO: 1. 添加请求超时和重试逻辑。2. 添加缓存（相同内容返回相同标签）。3. 优化prompt提升准确率。 """ prompt = f"""请为以下文章生成3-5个最相关的标签，以JSON数组格式返回，例如 ["科技", "人工智能"]。 标题：{title} 内容摘要：{content[:500]}... """ try: # TODO: 模型参数（如temperature）需要根据效果调整。 response = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=[{"role": "user", "content": prompt}], temperature=0.3 ) result = response.choices[0].message.content # FIXME: 这里直接解析JSON，如果AI返回格式不对会崩溃。 tags = json.loads(result) return tags except Exception as e: # TODO: 需要更细致的错误处理和降级策略（如返回空列表或默认标签）。 print(f"生成标签失败: {e}") return []

   这个函数问题一大堆：密钥硬编码、没有错误处理、没有缓存、prompt可能不精准、JSON解析脆弱。但它能用。从想法到上线，可能只需要半天。
3. 交付与收集反馈：把这个函数集成到文章发布流程中，立刻就有了一批带标签的文章。业务方和运营同学马上就能看到效果，并给出反馈：“标签有时候不太准”、“能不能多生成几个？”、“有些标签太宽泛了”。
4. 迭代与“填坑”：根据反馈，你开始用AI助手“填坑”。
   • 反馈1：标签不准。你让AI帮你优化prompt：“基于以下示例（给出几个标题、内容和理想标签），优化这个生成标签的prompt，使其更准确、更具体。” AI会给你一个更好的prompt。
   • 反馈2：需要缓存。你让AI重构函数：“为这个generate_tags_naive函数添加一个基于文章内容MD5的本地内存缓存，缓存时间1小时。注意线程安全。” AI生成带lru_cache或functools.cache的版本。
   • 技术债1：密钥管理。你让AI修改代码：“将硬编码的API密钥改为从环境变量OPENAI_API_KEY读取，如果不存在则抛出清晰的错误信息。”
   • 技术债2：健壮性。你让AI增强代码：“为这个函数添加完整的错误处理：网络超时（设置10秒）、重试（最多2次）、JSON解析失败后的fallback（尝试提取文本中的标签词）、以及最后的降级策略（返回空列表）。并添加结构化日志（使用logging模块）。”

通过“挖坑-反馈-填坑”的循环，你用极短的时间交付了核心价值，并在实际使用中收集到真实反馈来指导优化。而那些一开始就花大力气设计的“可插拔模型框架”，可能直到项目下线都没用上第二个实现。

6. 平衡的艺术：何时该坚持“洁癖”，何时该果断“挖坑”

“挖坑”不是万能药，更不是写烂代码的借口。它是一种基于上下文权衡的工程决策。那么，边界在哪里？

6.1 必须坚持“洁癖”、拒绝挖坑的场景

1. 安全与隐私：任何涉及用户密码、支付信息、个人敏感数据的处理逻辑，必须从一开始就严谨。加密算法是否正确？密钥管理是否安全？有没有SQL注入或XSS漏洞？这些地方不容有失，必须追求“洁癖”。
2. 核心数据模型与接口：系统的核心领域模型、数据库的主要表结构、模块间最重要的API接口。这些是系统的骨架，一旦定下来再改，成本极高。在设计时需要多花时间思考，保持简洁和前瞻性，避免在这里“挖坑”。
3. 公共库与基础设施代码：你团队维护的、会被多个项目引用的公共组件、工具库或框架。这里的代码质量会影响所有使用者，必须高标准严要求，有完善的测试、文档和版本管理。
4. 算法正确性：对于排序、搜索、计算等核心算法，其正确性是第一位的。一个错误的算法，即使再快、代码再简洁，也是无用的。这里需要的是数学上的严谨，而不是速度上的妥协。

6.2 鼓励“挖坑”、快速推进的场景

1. 探索性项目与原型验证：当你不知道一件事能不能成的时候，最快的验证方式就是“挖坑”做出一个原型。用最直接、甚至有点“脏”的方法，看到效果，验证假设。
2. 非关键路径的辅助功能：比如后台的管理页面、数据统计看板、一次性的数据迁移脚本、内部的工具小插件。这些功能不直接影响核心用户体验，可以接受一定的粗糙度，快速实现。
3. 已知的、有明确修复计划的临时方案：比如为了应对突发的流量高峰，临时给数据库加一层缓存。你知道这个缓存策略有缺陷（比如缓存穿透），但你也明确计划在一周后升级为更完善的方案。这时，可以接受一个临时的“坑”。
4. 受外部强时间约束时：比如应对紧急线上故障的补丁、老板明天就要看的演示Demo、配合市场活动的临时上线需求。在时间压倒一切的情况下，优先保证功能可用，同时标记好所有临时措施。

判断的核心标准是：这个决策的“ reversible”（可逆性）成本有多高？如果未来修改的成本很低（比如一个独立的函数、一个配置项），那么可以更激进地“挖坑”。如果修改成本很高（比如修改数据库核心表结构、调整分布式系统的通信协议），那么就必须更谨慎。

7. 与AI协作下的新工作流：从“工匠”到“指挥官”

AI编码助手的普及，不仅仅是多了一个写代码的工具，它正在重塑我们的工作流和角色定位。传统的开发者像“工匠”，亲手雕琢每一块砖瓦。而未来的开发者，更像“指挥官”或“产品工程师”，负责定义问题、制定策略、验收结果，而将具体的“施工”任务交给AI。

在这个新工作流下，“挖坑”思维变得更加自然和高效：

1. 构思与指令设计：你的主要工作不再是敲键盘，而是思考。“我要实现一个什么功能？”“这个功能的核心逻辑是什么？”“有哪些边界情况？”“我希望代码最终长什么样？”然后，将这些思考转化为给AI的清晰、具体的指令（Prompt）。这本身就是一种更高级的设计。
2. 验收与迭代：AI生成代码后，你不再是“代码作者”，而是“代码审查者”和“产品验收者”。你关注的是：逻辑是否正确？是否覆盖了所有场景？性能是否达标？API设计是否合理？如果有问题，不是自己动手改，而是给AI新的指令：“这里需要处理网络超时，请加上重试机制。”“这个函数的参数太多了，请重构为使用一个配置对象。”
3. “挖坑”与“填坑”的流水线：你可以系统性地管理技术债。每周或每个迭代，可以专门安排一个“AI填坑时间”。把代码库里的TODO、FIXME列表拿出来，一条条地交给AI去处理。你负责审核结果。这样，技术债的偿还变成了一个可规划、可度量的常规工作，而不是压在心里的负担。

这种模式下，你对代码的“洁癖”从“对每一行代码的语法和格式的苛求”，上升为“对整体设计、逻辑完备性和最终效果的苛求”。你放下了对局部“整洁”的执念，转而追求全局的“高效”和“正确”。你不再害怕代码中有不完美的地方，因为你拥有了一个强大且不知疲倦的伙伴，可以随时帮你把这些不完美变得更好。

所以，放下那些不必要的代码洁癖吧。它不是你的勋章，可能是你前进的枷锁。拥抱“挖坑”思维，不是要你变得邋遢，而是让你变得更务实、更敏捷。把有限的精力集中在真正需要人类创造力和判断力的事情上，把那些重复的、繁琐的“填坑”工作，交给AI。你会发现，你不仅能更快地交付价值，还能在不断的“挖坑-填坑”循环中，更深刻地理解问题本身，从而成为一个更优秀的工程师。这，就是属于AI时代的“享受挖坑人生”。