我的2026开发者工作流：结合良好的工程习惯与AI工具
I’m happy to help translate the article, but I’ll need the text you’d like translated. Could you please paste the content of the article (or the portions you want translated) here? I’ll then provide the Simplified Chinese version while preserving the source link, formatting, and any code blocks or URLs.
在2026年，几乎比使用AI更难避免AI
代码编辑器会建议完整的函数，终端会回应你，而且总有某个模型承诺“为你完成其余工作”。与此同时，我们构建的系统并没有 magically 变得更简单。错误依然真实存在，生产环境也不在乎你的代码是人写的还是模型生成的。
在本文中，我想展示一些非常具体的内容：我的日常开发者工作流在2026年到底是怎样的——包括AI，但并不被AI 所支配。我将逐步说明我如何组织工作，AI 在哪里介入，以及我有意回归“老派”工程的地方。
这不是一份“必须使用的10款工具”清单。这是一套在速度与控制之间取得平衡的现实工作流。
1. 从问题出发，而不是从工具出发
AI 最大的陷阱在于从“我能用这个模型做什么？”开始，而不是从“我在解决什么问题？”
所以我的一天仍然以传统方式开始：
- 我需要的结果是什么？
- 系统的哪些部分会受到影响？
- 这种变化会如何呈现给用户？
我通常会把这些写在仓库里的一个简单文本或 markdown 文件中。比如：
feature: allow users to export reports as CSV
constraints: must not block the UI; runs in background; notify user when ready
touched areas: API, background jobs, notification system
edge cases: large report size, timeouts, permissions只有在我把这个粗略的框架勾勒出来后，才会把 AI 拉进来。如果跳过这一步，直接去“生成代码”，我几乎总会在后面为此付出代价。
2. 将 AI 作为设计伙伴，而非代码售卖机
在我编写任何代码之前，我经常使用 AI 来探索设计方案。我通常会问：
- “在这种背景下，有哪些 2–3 种合理的方式来设计此功能？”
- “方案 A 与方案 B 之间的权衡是什么？”
- “对于这种变更，我应该考虑哪些失效模式？”
我会粘贴系统和问题的简短描述（绝不涉及专有机密，对于敏感项目我更倾向于使用 本地模型），并请求 高层次的建议，而非代码。
我得到的回复很少是完美的，但它帮助我及早发现盲点。有时它提醒我忘记的模式；有时它揭示了只有在压力下才会发现的边缘情况。
重要一点： 我使用 AI 来拓宽思路，但最终的设计决策仍由我自己做出。
3. 编写代码的第一版——人类先行，AI 作为加速器
在实际写代码时，我的原则很简单：
| 情境 | 方法 |
|---|---|
| 小的东西（辅助函数、直接的胶水代码） | 让 AI 提供大部分代码建议 |
| 核心逻辑和复杂流程 | 我自己写结构；仅使用 AI 填充细节 |
典型的模式：
- 我编写 函数签名、文档字符串，以及几行解释应当如何工作的注释。
- 我在编辑器中让 AI 完成实现。
- 我立即 审查并“拥有”结果——把它当作是初级开发者写的代码来阅读。
如果我发现自己在没有阅读的情况下直接接受整文件，那就是警示信号。AI 是极好的自动补全工具，但它 不承担 责任。我 承担。
4. 先写测试‑ish：AI 帮得上忙的地方和会带来麻烦的地方
我并不是一个“永远 TDD”的完美实践者。有时我先写测试，有时在第一稿之后才写。但我注意到一点：在 AI 辅助的世界里，测试比以前更为重要。
我在测试方面使用 AI 的方式有两种：
- 起草我可能遗漏的测试用例和边界情况
- 生成枯燥的模板代码（fixture、参数化测试数据等）
示例提示
Write unit tests for a function that generates CSV exports from a list of records.
Important cases: empty list, records with special characters in fields,
very large lists that should be streamed or chunked.AI 会给我一套起始测试。随后我会：
- 裁剪 那些冗余或不切实际的测试。
- 添加 与我的系统特定相关的用例。
- 确保 名称和结构与其余测试套件保持一致。
目标 不是 让 AI 决定“完成”的标准，而是利用它更快地实现有意义的覆盖率。
5. 使用 AI 进行重构和解释
一旦某个功能正常工作并且已有测试覆盖，我常常再次使用 AI 来改进它。我具体会请求以下事项：
- “重构此函数，使控制流更清晰。”
- “将验证逻辑提取到一个单独的辅助函数，并建议一个合适的名称。”
- “用通俗的英文解释这段代码，以便我添加有用的注释。”
有时我会把一段复杂的函数粘贴给助手，让它解释其行为。当我在处理自己未编写的旧代码时，这尤其有用。
硬性规则： 重构必须遵循与人工编写相同的流程。
- 运行测试。
- 快速浏览 diff，并留意任何意外的更改。
- 拒绝 那些让代码更巧妙但更晦涩的重构。
AI 善于重命名和重构代码，但在把握团队对“过于巧妙”的容忍度方面表现糟糕。
6. AI 在 DevOps 循环中的应用：脚本、配置和事件
除了编辑器之外，我还在 DevOps 任务中使用 AI——但仍然设有界限。
| 任务 | 示例提示 | 审核步骤 |
|---|---|---|
| Shell 单行命令和小脚本 | “编写一个 Bash 脚本，查找 /var/log 中所有大于 1 GB 的日志文件并压缩它们，同时保留带时间戳的备份。” | 在运行之前审查脚本，或先在安全环境中运行。 |
| CI/CD 配置片段 | “展示一个 GitHub Actions 工作流，在 push 时运行测试，并在 main 分支上构建 Docker 镜像。” | 根据项目进行适配，而不是盲目复制。 |
| 事件记录与摘要 | 粘贴原始聊天记录和笔记 → “起草一份结构化的事件报告。” | 在发布前修正并完善草稿。 |
我不做的事情： 让 AI 在没有明确人工审核和防护措施的情况下直接对生产系统执行更改。
7. 保持界限：我有意不使用 AI 的地方
正如我在之前的文章中所说（原文在此处截断；其意在说明我有意保留盲区，排除 AI 的使用，例如安全关键代码、法律合规，或任何错误可能导致灾难性后果的领域。）
TL;DR
- 从问题出发，而不是工具。
- 将 AI 作为 设计伙伴 和 加速器 使用，而不是判断的替代品。
- 对 你交付的每一行代码负责；把 AI 生成的代码片段视作初级同事的贡献。
- 积极测试；让 AI 帮助你编写测试，但要自行验证。
- 将 AI 用于 重构、解释 和 DevOps，并以同样严格的审查标准对待这些更改，就像对待任何人工编写的代码一样。
- 对安全敏感、合规繁重或生产关键的工作 划清明确界限。
通过保持这些界限，AI 将成为强大的盟友，而不是隐藏的风险来源。
AI 边界
在我的开发工作流程中，有一些领域我会非常谨慎，甚至完全避免使用 AI：
- 敏感代码和数据 – 任何如果泄露会造成问题的内容，都不会使用通用云模型。为此，我要么使用本地模型，要么根本不使用 AI。
- 安全关键逻辑 – 我可以让 AI 帮助我思考威胁模型和测试用例，但绝不让它从头到尾编写认证、密码学或支付相关的逻辑。
- 性能敏感热点 – 对于紧凑循环或关键性能路径，我可能会请 AI 提出思路，但最终实现完全由我掌控。
8. 比任何工具都更重要的日常习惯
- 小而聚焦的提交，附带清晰的说明
- 快速且可靠的测试
- 诚实的代码审查，而不仅仅是 “LGTM”
- 简洁、易读的代码胜过巧妙的一行代码
- 定期重构，而不是一次性 “大清理周”
AI 如何支持这些习惯
- 它可以帮助你编写更好的提交说明。
- 它可以建议测试。
- 它可以在代码审查中发表评论，指出你可能遗漏的地方。
但如果基础习惯已经被破坏，这一切都无济于事。
我的2026工作流程
- 清晰地思考问题。
- 在设计和探索阶段早期使用AI。
- 在编辑器中将AI作为加速器使用，而不是自动驾驶。
- 通过测试和评审来保障质量。
- 在代码周边（脚本、文档、事件）使用AI，以减少胶水工作。
- 保持严格的边界，以防错误造成严重后果。
如果你把AI视为已经稳固的工作流中的强大助手，使用起来会非常自然。如果你尝试从零开始围绕AI构建工作流，你会花更多时间与工具抗争，而不是交付有用的代码。