1. 从“赶工”到“思考”AI如何重塑前端工程的核心价值我干了十多年软件工程从写第一行HTML到负责大型前端架构有一个场景我见过无数次项目启动会上大家激情澎湃地讨论着优雅的架构、清晰的边界、可维护的状态设计然后第一个deadline逼近所有那些美好的设想瞬间被“先跑起来再说”的洪流冲垮。我们不是不知道怎么做更好而是“没时间”。这个“没时间”成了过去十年里无数技术债、混乱代码库和“考古项目”的万能借口。最近一年随着AI编码工具的普及一个有趣的现象发生了大家欢呼“生产力提升了”但很多人没意识到这场变革真正的礼物不是让你更快地敲出烂代码而是把“思考的时间”还给了工程师。AI没有降低对资深工程师的要求恰恰相反它放大了“决策”与“执行”之间的价值鸿沟。一个初级工程师借助Copilot或Claude可能更快地产出语法正确、结构看似合理的代码这缩小了“实现能力”的差距。但一个资深工程师在同样的工具加持下其价值跃升是指数级的。因为工具替他承担了繁重的“翻译”工作——将清晰的设计意图转化为具体的代码行——从而释放出他全部的心智带宽用于完成那些真正决定项目生死的工作定义问题边界、设计抗变更的架构、进行状态建模、预判未来的扩展点。这不再是“一个人干两个人的活”而是“一个人干一个架构师团队的活”。当实现变得廉价前期思考的质量就成了唯一的稀缺资源。这篇文章我想结合一个真实的“战舰”游戏前端项目拆解一套我称之为“带约束的工作流”的实践。它不是什么银弹而是一个强制性的纪律系统核心目标就一个利用AI带来的时间盈余把那些我们“知道很重要但总没空做”的事变成开发流程中不可跳过的环节。无论你是独立开发者还是团队Tech Lead这套方法都能帮你把AI从“加速打字的工具”转变为“高质量系统的孵化器”。2. 核心范式转变从“实现瓶颈”到“决策瓶颈”在深入工作流细节之前我们必须先统一认知AI到底改变了什么主流叙事集中在“吞吐量”上——生成样板代码、自动补全、更快地实现功能。这没错但这只是最表层的变化。更深层的解锁是认知性的。2.1 重新审视“速度”的定义传统开发中“速度”往往被等同于“编码速度”。项目经理盯着燃尽图工程师被功能点追赶我们陷入一个恶性循环因为没时间设计所以写出的代码耦合度高、难以修改因为代码难以修改后续每个需求都要花更长时间于是更没时间设计。AI工具打破了“编码”这个环节的耗时但如果我们只是用更快的速度冲向错误的方向结果就是“更早地抵达失败”。一个瞄准错误问题、但结构完美的代码库其失败来得比以往任何时候都快。因此新的“速度”必须被重新定义为“从正确理解问题到交付正确解决方案的整体周期时间”。AI缩短的是后半段实现而我们要用 reclaimed time重新获得的时间去加强前半段理解与设计。这要求工作流有一个根本性的重构。2.2 “资深系数”的放大效应很多管理者犯了一个错误看到初级工程师AI能产出更“像样”的代码便认为资深工程师的价值被稀释了。这是典型的见木不见林。真正的价值跃迁发生在另一端资深工程师AI能产生的输出接近于过去一个5-10人资深团队才能达到的设计与系统质量。原因在于资深工程师的核心竞争力从来不是“写for循环写得快”而是问题定义能力在需求模糊时能通过追问澄清真正的商业目标避免解决一个错误的问题。抽象与建模能力能将混乱的现实世界需求抽象为清晰、边界合理的软件模型状态、关系、行为。预见性设计能力能预见到需求可能的变更方向并设计出能容纳这种变更的架构避免推倒重来。权衡决策能力能在性能、可维护性、开发速度、技术风险之间做出明智的取舍。质量内建能力能将可测试性、可访问性、安全性等非功能需求设计到系统骨架中而不是事后补救。AI工具无法自动获得这些能力。但它可以把工程师从繁琐的代码实现中解放出来让他们能百分百地聚焦于这些高杠杆活动。一个简单的类比以前资深工程师60%的时间在“挖沟”写具体代码40%在“画蓝图”设计。现在AI能承担80%的“挖沟”工作那么资深工程师就可以把90%的时间用于“画蓝图”和“现场监理”产出的系统质量自然不可同日而语。3. “带约束的工作流”详解五阶段强制纪律下面这套工作流是我在多个项目中实践并固化下来的。它不是一个松散的“最佳实践建议”而是一个强制性的、阶段化的命令序列。每个阶段都是一个明确的“检查点”前一阶段未完成绝不进入下一阶段。这听起来死板但正是这种死板杜绝了“边做边想”导致的混乱。3.1 第一阶段飞行前检查Preflight—— 禁止写代码这是整个工作流中最重要、也最反直觉的一步。在此阶段严格禁止生成任何代码。它的唯一目的是对齐认知、探查战场。具体操作指令给AI的指令范例/cmd-preflight这个指令要求AI或工程师自己完成以下动作通读架构约束文档例如项目中的CLAUDE.md或ARCHITECTURE.md。这份文档定义了所有“宪法级”规则分层架构如视图层、服务层、引擎层、状态管理规范、TypeScript严格模式设置、可访问性要求、测试策略等。搜索现有代码库寻找与当前任务相关的现有类型、工具函数、业务逻辑。目的是最大化复用避免重复造轮子。识别正确层级根据架构分层确定新功能或修改应该属于哪一层是纯逻辑的引擎层是协调数据的服务层还是表现层的组件。陈述变更增量用一句话清晰地描述每个需要创建或修改的文件将要发生什么变化。例如“在src/services/gameLogic.ts中新增validateShipPlacement函数用于替代utils/中散落的校验逻辑。”为什么这一步至关重要对齐预期当AI生成的Preflight报告与你脑中的设计模型一致时你们在写第一行代码前就建立了可验证的共同基线。暴露未知当报告指出你没想到的现有工具、模糊的层级归属、或未检验的假设时你就在真正付出编码成本之前发现了自己系统中的认知盲区。这些盲区正是未来Bug的温床和重构失败的地方。设定范围清晰的“一句话描述”是衡量需求是否明确的试金石。如果描述不清说明需求本身或你的理解还不清晰必须停下来澄清。实操心得我习惯把Preflight的输出当成一次微型的设计评审。即使是我一个人开发我也会强迫自己把这份报告读一遍假装在给同事讲解。这个过程常常能发现一些“想当然”的漏洞。有一次在为一个购物车添加优惠券功能前Preflight阶段发现“折扣计算”的逻辑在订单服务、商品服务和促销服务中各有碎片化实现。这直接促使我先进行了一次小范围重构统一了计算入口然后再开发新功能避免了更大的混乱。3.2 第二阶段计划Plan—— 产出可评审的规格说明书经过Preflight我们知道了“有什么”和“要做什么”。Plan阶段的目标是产出“具体怎么做”的详细规格书这仍然是一份文档而不是代码。具体操作指令/cmd-plan这个指令要求产出包含以下内容的计划文档新类型定义每个新类型的名称、结构Shape、以及为什么需要它。新函数签名每个新函数的完整签名参数、返回值、它所属的架构层、是否是纯函数、以及测试策略单元测试、集成测试、不测试。状态变更描述哪些状态需要持久化哪些是派生状态理由是什么。组件接口新组件的Props接口定义以及它发出的事件。可访问性影响评估对无障碍访问的影响及应对措施。风险标识识别出实现中可能的风险点如第三方API稳定性、浏览器兼容性等。文件变更清单再次确认并列出所有需要创建或修改的文件每个附上一句话描述。这个计划是一个检查点不是建议。它必须得到明确的批准哪怕是自己对自己点头认可才能进入下一阶段。如果计划有误在这里修改的代价是修改几行文本如果在代码中才发现问题代价就是一次痛苦的撤销、重写和可能的回归测试。3.3 第三阶段实现Implement—— 在约束内编码只有当前两个阶段都得到确认后我们才进入编码阶段。这个阶段反而可能是最“轻松”和“快速”的因为所有重大决策都已做出范围已被锁定。具体操作指令/cmd-implementAI或工程师根据批准的计划一次完整地实现一个文件。这里的关键纪律是严禁范围蔓延计划就是法律。如果在编码时想到了一个“很棒”但不在计划内的点子必须记录下来放入后续任务的待办事项而不是当场加入。严禁重复发明严格复用Preflight阶段发现的现有工具和模式。遵循架构约束每一行代码都必须符合CLAUDE.md中定义的架构规则。在这个阶段AI的价值得到最大化体现。它像一个极度熟悉公司编码规范、且不知疲倦的初级工程师精准地将高级设计翻译成可靠的代码。而你作为资深工程师扮演的是架构师和监理的角色确保翻译的准确性而不是亲自去搬砖。3.4 第四阶段验证Verify—— 自动化质量门禁代码写完了但在进行人工评审之前必须通过一系列自动化的验证关卡。这个阶段的目标是交给人类评审的代码在基础质量层面必须是“干净”的。具体操作指令/cmd-verify这个命令会触发一个自动检查清单通常包括架构合规性检查确保没有违反分层原则例如引擎层引入了React依赖。TypeScript类型检查运行tsc --noEmit确保零类型错误。代码风格检查运行Linter如ESLint。测试套件运行运行所有相关单元测试和集成测试确保通过。可访问性规则检查如果配置了相关插件如eslint-plugin-jsx-a11y进行自动检测。CI模拟运行与持续集成环境相同的构建和测试命令。任何一项检查失败都必须在此阶段修复。AI不应该也绝不允许将一个已知存在基础质量问题的变更提交评审。这就像工厂的质检环节不合格品不会流到下一条流水线。3.5 第五阶段评审Review—— 聚焦于决策与权衡经过Verify的代码其语法正确性和基础合规性已有保障。因此人工代码评审无论是自我评审还是同伴评审就可以从繁琐的“找语法错误”、“检查缩进”中解放出来聚焦于真正需要人类智慧的地方具体操作指令/cmd-review评审阶段关注的是设计决策与权衡为什么选择方案A而不是方案B这个折中考虑了哪些因素未来影响这个改动会对系统的其他部分或未来扩展产生什么潜在影响待办事项在实现过程中发现但属于当前任务范围外的问题被明确记录为“延迟观察项”而不是悄悄塞进本次修改。需要签核的项哪些决策需要更高级别或更广泛团队的知晓与同意。这个阶段的输出常常是更新架构文档 (ARCHITECTURE.md) 中的“关键讨论点”部分记录下重要的设计决策及其上下文。这极大地减轻了未来的“考古”成本。4. 实战推演以“战舰游戏CLI运行器”为例理论说了这么多我们来看一个从我真实项目一个React TypeScript战舰游戏中截取的任务实例。目标是为已有的纯逻辑游戏引擎创建一个命令行界面(CLI)运行器。核心约束游戏引擎层是纯粹的(state, action) newState函数没有任何React依赖。CLI必须能直接消费这个引擎使用完全相同的reducer、服务和类型且不允许修改任何现有领域代码。这是对架构边界是否真实的终极测试。以下就是交给AI的完整任务提示文档。请注意它不仅仅描述了“要做什么”更嵌入了工作流的执行指令# 任务实现CLI运行器 **上下文** 引擎层是纯函数状态动作 新状态无React依赖。终端运行器应直接消费它——相同的reducer、相同的服务、相同的类型——且对现有代码零修改。这将验证分层边界是真实存在的。 **事前决策不得重新讨论** - src/cli/ 目录下任何地方不允许出现React导入。 - CLI中不包含游戏规则——只有I/O、渲染和驱动引擎。 - LineReader 接口抽象Node的readline避免在vite/client类型作用域下导入Node类型。 - 无颜色、无ANSI格式化、无AI射击延迟——终端输出是同步的延迟无意义。 - 无布置战舰阶段——两种模式都使用 generateRandomLayout。 - 不为 src/cli/ 编写测试——所有有意义的逻辑都已被引擎和服务测试覆盖。 **待创建文件4个** - src/cli/index.ts —— 入口点模式和难度菜单readline生命周期循环。 - src/cli/loop.ts —— 单人模式和对抗电脑模式的游戏循环。 - src/cli/renderer.ts —— 纯字符串渲染棋盘网格射击结果游戏结束信息。 - src/cli/input.ts —— 坐标解析器readline提示循环LineReader接口。 **待修改文件2个** - tsconfig.cli.json —— 确认CLI入口点配置正确。 - docs/ARCHITECTURE.md —— 新增CLI章节记录消费者模式及AI延迟的故意省略。 **类型** - input.ts 中的 LineReader 接口{ question(prompt: string, cb: (answer: string) void): void; close(): void } —— 抽象readline无需导入Node类型。 - 无新的领域类型——全部使用来自 engine/、services/、types/ 的现有类型。 **函数** - renderBoard(boardState: BoardState, label: string): string —— 纯字符串函数无副作用可单元测试。 - parseCoordinateInput(input: string, boardSize: number): Coordinate | null —— 纯函数输入无效时返回null。 - runSinglePlayerLoop(rl: LineReader, difficulty: Difficulty): Promisevoid —— 异步直接驱动引擎reducer。 - runVsComputerLoop(rl: LineReader, difficulty: Difficulty): Promisevoid —— 异步相同模式。 **状态** - 无新状态。CLI将引擎reducer作为普通函数驱动state reducer(state, action)。 **可访问性影响**无——仅限终端。 **必需的AI工作流** 1. /cmd-preflight —— 通读 CLAUDE.md搜索与本任务相关的现有引擎reducer、服务函数和类型。确认 src/cli/ 尚不存在。运行 npx tsc -p tsconfig.json --noEmit、npm test、npm run lint。如有任何失败不得继续。 2. /cmd-plan —— 生成完整的实现计划涵盖类型、函数签名、文件列表及 ARCHITECTURE.md 更新。在获得明确批准前不得编写任何代码。 3. /cmd-implement —— 按此顺序实现input.ts、renderer.ts、loop.ts、index.ts然后更新 docs/ARCHITECTURE.md。一次完成一个文件。禁止范围蔓延。 4. /cmd-verify —— 确认 src/cli/ 中零React导入未从服务层重复任何领域逻辑TypeScript检查通过所有现有测试仍能通过。 5. /cmd-review —— 明确展示决策、权衡以及故意省略AI延迟的原因。标记任何需要签字确认的事项。 **风险标识** - crypto.randomUUID 可能并非在所有Node版本中都可用——需确认或使用 Math.random 回退方案。 - AI射击延迟被故意省略——需明确记录以免未来阅读者将其加回。 **测试计划** - 无CLI专项测试。引擎、服务和渲染器纯函数已被现有及新增的单元测试覆盖。 - renderer.ts 和 input.ts 如需可在日后单独测试。 **验收标准** - npm run cli 可启动游戏。 - 单人模式和对抗电脑模式均可端到端运行。 - 难度选择功能正常。 - 射击输入解析正确对无效输入给出提示信息。 - 能检测并报告游戏结束。 - 对 engine/、services/、utils/、types/、constants/ 的修改为零。 - src/cli/ 目录中无任何React导入。 - docs/ARCHITECTURE.md 已更新CLI章节。 **禁止事项** - 禁止在 src/cli/ 的任何地方导入React。 - 禁止从 services/ 重复任何规则逻辑。 - 禁止添加AI射击延迟。 - 禁止添加布置阶段。 - 禁止提交——在评审批准后即停止。这份文档就是开发前的“宪法”。AI将严格依据它来执行。最终产出的会是一个单一、可评审、目的明确的提交而不是一个包含40个文件、毫无清晰叙事的巨大差异对比。原子化的提示产生原子化的提交。Git历史保持可读代码评审保持可管理。这不是工作流的副作用而是在动代码之前就定义好范围所带来的结构性成果。5. 支撑系统编码知识库与领域技能工作流的命令序列只是触发器真正赋予其力量的是背后的约束系统——即编码化的团队知识与领域规则。没有这个工作流就只是一套提示词模式有了它才是一个完整的工程系统。在我的项目中这体现为两个层面CLAUDE.md工程标准文档这是一个活的文档定义了所有架构层面的“宪法”。例如分层契约严格定义引擎层、服务层、工具层、UI层之间的依赖方向和数据流。比如“引擎层不得导入任何UI框架相关模块”。状态设计规则规定哪些状态是可变的、哪些是只读的、状态更新的唯一路径是什么。坐标处理规范所有棋盘坐标必须使用{ row: number; col: number }对象禁止使用数组或字符串拼接等临时表示。TypeScript配置开启strict: true禁止使用any必须为函数返回值显式定义类型等。可访问性规则所有交互式组件必须可通过键盘操作图片必须有alt文本等。测试策略纯函数必须单元测试组件测试使用Testing Library集成测试覆盖核心用户流程。领域技能库.claude/skills/这是一系列针对特定领域知识的编码文件AI在相关上下文会自动加载。例如react-architecture.md包含React项目分层的最佳实践、状态提升与下放的判断逻辑、自定义Hook的编写规范。wcag-react.md针对React的具体可访问性实现模式如表单标签关联、焦点管理、ARIA属性使用示例。vitest-react.md定义如何使用Vitest和React Testing Library编写测试包括Mock策略和渲染辅助函数。这套系统的威力在于它让AI不必在每次会话中重新“发现”或“猜测”团队规则。规则被白纸黑字地写下来进行版本控制并且每次任务都可用。这极大地减少了沟通开销和上下文切换成本确保了输出的一致性。工程师不再需要反复口述“我们这里规定要……”只需要说“请遵循CLAUDE.md和react-architecture技能”。6. 常见陷阱与心智模型调整即使理解了工作流在实际推行中也会遇到阻力。以下是一些常见的陷阱及应对策略陷阱一“这太慢了不如直接开干。”错觉跳过前期思考似乎更快。现实在复杂项目中因前期理解偏差导致的返工、调试和沟通成本远超前期投入的思考时间。工作流强制进行的“慢思考”实际上是通过降低返工率来提升整体速度。第一个任务可能最“费时”但第五十个任务会因此变得流畅而清晰。陷阱二“AI能自己搞定我只需要审核代码。”风险沦为被动的代码审核者将设计主动权让渡给AI。正确姿势你必须是设计的主导者。AI是执行者。Preflight和Plan阶段是你输出设计意图、让AI对齐的过程。你的价值体现在提出正确的问题、识别AI方案中的潜在缺陷、做出关键的架构权衡。陷阱三约束文档如CLAUDE.md变成一纸空文。问题制定了规则但执行不严格逐渐失效。解决方案将规则验证自动化。在Verify阶段通过脚本或工具如自定义ESLint规则、架构依赖关系检查工具自动检查是否违反CLAUDE.md中的关键约束。让机器来守护规则。陷阱四过度设计陷入“分析瘫痪”。平衡点工作流不是鼓励无休止的设计。Preflight和Plan阶段应该有明确的时间盒。目标是产出“足够好、可演进”的设计而不是“完美无缺、涵盖一切”的设计。关键在于识别出那些一旦错误代价高昂的决策如核心数据模型、系统边界在这些地方投入精力对于那些容易修改的细节可以适当放宽。陷阱五忽略了知识库的维护。关键CLAUDE.md和技能库不是静态的。随着项目演进和技术栈更新它们也需要迭代。建立一个轻量级的流程当团队遇到重复性的设计决策或发现新的最佳实践时将其总结并更新到知识库中。这本身就是一种宝贵的技术资产管理。7. 工具之外的思考回归工程的本源最后我想分享一个可能有些反潮流的观点AI工具并没有赋予你原本不具备的判断力它只是给了你时间去运用你已有的判断力。对于那些早已在思考架构、但总是被deadline追着跑、没有“跑道”去实践的工程师来说这是一个真正意义上的解放。时间这个最大的约束消失了。你可以像下棋一样先看三步再落子。但对于那些原本就习惯于“先行动、后思考”的团队或个人AI带来的可能只是“更快的错误产出”。区别会在六个月后显现一个代码库仍然可以清晰、干净地扩展另一个则变成了需要专人“考古”才能理解的废墟。“战舰”项目对我而言其目标从来不是构建一个游戏。它是一个载体用于演示当你有时间在写代码之前进行思考时一个具有纪律性的前端架构会是什么样子。最有力的证明不是React UI本身而是那个不依赖任何前端框架、直接消费同一套引擎逻辑的CLI运行器。而更有说服力的产物是那份docs/ARCHITECTURE.md文档它解释了代码库中每一个重要决策、每一个被考虑的替代方案以及选择背后的理由。这份文档在通常的工期压力下是写不出来的。不是因为工程师能力不足而是因为没有时间。约束从来不是知识而是时间。现在这个约束在很大程度上已经消失了。我们是否准备好将这份被归还的时间真正投入到那些决定系统长期生存能力的工作中去这才是AI带给软件工程最深远的挑战与机遇。
AI时代前端工程实践：从编码执行到架构决策的范式转变
发布时间：2026/5/28 6:03:16
1. 从“赶工”到“思考”AI如何重塑前端工程的核心价值我干了十多年软件工程从写第一行HTML到负责大型前端架构有一个场景我见过无数次项目启动会上大家激情澎湃地讨论着优雅的架构、清晰的边界、可维护的状态设计然后第一个deadline逼近所有那些美好的设想瞬间被“先跑起来再说”的洪流冲垮。我们不是不知道怎么做更好而是“没时间”。这个“没时间”成了过去十年里无数技术债、混乱代码库和“考古项目”的万能借口。最近一年随着AI编码工具的普及一个有趣的现象发生了大家欢呼“生产力提升了”但很多人没意识到这场变革真正的礼物不是让你更快地敲出烂代码而是把“思考的时间”还给了工程师。AI没有降低对资深工程师的要求恰恰相反它放大了“决策”与“执行”之间的价值鸿沟。一个初级工程师借助Copilot或Claude可能更快地产出语法正确、结构看似合理的代码这缩小了“实现能力”的差距。但一个资深工程师在同样的工具加持下其价值跃升是指数级的。因为工具替他承担了繁重的“翻译”工作——将清晰的设计意图转化为具体的代码行——从而释放出他全部的心智带宽用于完成那些真正决定项目生死的工作定义问题边界、设计抗变更的架构、进行状态建模、预判未来的扩展点。这不再是“一个人干两个人的活”而是“一个人干一个架构师团队的活”。当实现变得廉价前期思考的质量就成了唯一的稀缺资源。这篇文章我想结合一个真实的“战舰”游戏前端项目拆解一套我称之为“带约束的工作流”的实践。它不是什么银弹而是一个强制性的纪律系统核心目标就一个利用AI带来的时间盈余把那些我们“知道很重要但总没空做”的事变成开发流程中不可跳过的环节。无论你是独立开发者还是团队Tech Lead这套方法都能帮你把AI从“加速打字的工具”转变为“高质量系统的孵化器”。2. 核心范式转变从“实现瓶颈”到“决策瓶颈”在深入工作流细节之前我们必须先统一认知AI到底改变了什么主流叙事集中在“吞吐量”上——生成样板代码、自动补全、更快地实现功能。这没错但这只是最表层的变化。更深层的解锁是认知性的。2.1 重新审视“速度”的定义传统开发中“速度”往往被等同于“编码速度”。项目经理盯着燃尽图工程师被功能点追赶我们陷入一个恶性循环因为没时间设计所以写出的代码耦合度高、难以修改因为代码难以修改后续每个需求都要花更长时间于是更没时间设计。AI工具打破了“编码”这个环节的耗时但如果我们只是用更快的速度冲向错误的方向结果就是“更早地抵达失败”。一个瞄准错误问题、但结构完美的代码库其失败来得比以往任何时候都快。因此新的“速度”必须被重新定义为“从正确理解问题到交付正确解决方案的整体周期时间”。AI缩短的是后半段实现而我们要用 reclaimed time重新获得的时间去加强前半段理解与设计。这要求工作流有一个根本性的重构。2.2 “资深系数”的放大效应很多管理者犯了一个错误看到初级工程师AI能产出更“像样”的代码便认为资深工程师的价值被稀释了。这是典型的见木不见林。真正的价值跃迁发生在另一端资深工程师AI能产生的输出接近于过去一个5-10人资深团队才能达到的设计与系统质量。原因在于资深工程师的核心竞争力从来不是“写for循环写得快”而是问题定义能力在需求模糊时能通过追问澄清真正的商业目标避免解决一个错误的问题。抽象与建模能力能将混乱的现实世界需求抽象为清晰、边界合理的软件模型状态、关系、行为。预见性设计能力能预见到需求可能的变更方向并设计出能容纳这种变更的架构避免推倒重来。权衡决策能力能在性能、可维护性、开发速度、技术风险之间做出明智的取舍。质量内建能力能将可测试性、可访问性、安全性等非功能需求设计到系统骨架中而不是事后补救。AI工具无法自动获得这些能力。但它可以把工程师从繁琐的代码实现中解放出来让他们能百分百地聚焦于这些高杠杆活动。一个简单的类比以前资深工程师60%的时间在“挖沟”写具体代码40%在“画蓝图”设计。现在AI能承担80%的“挖沟”工作那么资深工程师就可以把90%的时间用于“画蓝图”和“现场监理”产出的系统质量自然不可同日而语。3. “带约束的工作流”详解五阶段强制纪律下面这套工作流是我在多个项目中实践并固化下来的。它不是一个松散的“最佳实践建议”而是一个强制性的、阶段化的命令序列。每个阶段都是一个明确的“检查点”前一阶段未完成绝不进入下一阶段。这听起来死板但正是这种死板杜绝了“边做边想”导致的混乱。3.1 第一阶段飞行前检查Preflight—— 禁止写代码这是整个工作流中最重要、也最反直觉的一步。在此阶段严格禁止生成任何代码。它的唯一目的是对齐认知、探查战场。具体操作指令给AI的指令范例/cmd-preflight这个指令要求AI或工程师自己完成以下动作通读架构约束文档例如项目中的CLAUDE.md或ARCHITECTURE.md。这份文档定义了所有“宪法级”规则分层架构如视图层、服务层、引擎层、状态管理规范、TypeScript严格模式设置、可访问性要求、测试策略等。搜索现有代码库寻找与当前任务相关的现有类型、工具函数、业务逻辑。目的是最大化复用避免重复造轮子。识别正确层级根据架构分层确定新功能或修改应该属于哪一层是纯逻辑的引擎层是协调数据的服务层还是表现层的组件。陈述变更增量用一句话清晰地描述每个需要创建或修改的文件将要发生什么变化。例如“在src/services/gameLogic.ts中新增validateShipPlacement函数用于替代utils/中散落的校验逻辑。”为什么这一步至关重要对齐预期当AI生成的Preflight报告与你脑中的设计模型一致时你们在写第一行代码前就建立了可验证的共同基线。暴露未知当报告指出你没想到的现有工具、模糊的层级归属、或未检验的假设时你就在真正付出编码成本之前发现了自己系统中的认知盲区。这些盲区正是未来Bug的温床和重构失败的地方。设定范围清晰的“一句话描述”是衡量需求是否明确的试金石。如果描述不清说明需求本身或你的理解还不清晰必须停下来澄清。实操心得我习惯把Preflight的输出当成一次微型的设计评审。即使是我一个人开发我也会强迫自己把这份报告读一遍假装在给同事讲解。这个过程常常能发现一些“想当然”的漏洞。有一次在为一个购物车添加优惠券功能前Preflight阶段发现“折扣计算”的逻辑在订单服务、商品服务和促销服务中各有碎片化实现。这直接促使我先进行了一次小范围重构统一了计算入口然后再开发新功能避免了更大的混乱。3.2 第二阶段计划Plan—— 产出可评审的规格说明书经过Preflight我们知道了“有什么”和“要做什么”。Plan阶段的目标是产出“具体怎么做”的详细规格书这仍然是一份文档而不是代码。具体操作指令/cmd-plan这个指令要求产出包含以下内容的计划文档新类型定义每个新类型的名称、结构Shape、以及为什么需要它。新函数签名每个新函数的完整签名参数、返回值、它所属的架构层、是否是纯函数、以及测试策略单元测试、集成测试、不测试。状态变更描述哪些状态需要持久化哪些是派生状态理由是什么。组件接口新组件的Props接口定义以及它发出的事件。可访问性影响评估对无障碍访问的影响及应对措施。风险标识识别出实现中可能的风险点如第三方API稳定性、浏览器兼容性等。文件变更清单再次确认并列出所有需要创建或修改的文件每个附上一句话描述。这个计划是一个检查点不是建议。它必须得到明确的批准哪怕是自己对自己点头认可才能进入下一阶段。如果计划有误在这里修改的代价是修改几行文本如果在代码中才发现问题代价就是一次痛苦的撤销、重写和可能的回归测试。3.3 第三阶段实现Implement—— 在约束内编码只有当前两个阶段都得到确认后我们才进入编码阶段。这个阶段反而可能是最“轻松”和“快速”的因为所有重大决策都已做出范围已被锁定。具体操作指令/cmd-implementAI或工程师根据批准的计划一次完整地实现一个文件。这里的关键纪律是严禁范围蔓延计划就是法律。如果在编码时想到了一个“很棒”但不在计划内的点子必须记录下来放入后续任务的待办事项而不是当场加入。严禁重复发明严格复用Preflight阶段发现的现有工具和模式。遵循架构约束每一行代码都必须符合CLAUDE.md中定义的架构规则。在这个阶段AI的价值得到最大化体现。它像一个极度熟悉公司编码规范、且不知疲倦的初级工程师精准地将高级设计翻译成可靠的代码。而你作为资深工程师扮演的是架构师和监理的角色确保翻译的准确性而不是亲自去搬砖。3.4 第四阶段验证Verify—— 自动化质量门禁代码写完了但在进行人工评审之前必须通过一系列自动化的验证关卡。这个阶段的目标是交给人类评审的代码在基础质量层面必须是“干净”的。具体操作指令/cmd-verify这个命令会触发一个自动检查清单通常包括架构合规性检查确保没有违反分层原则例如引擎层引入了React依赖。TypeScript类型检查运行tsc --noEmit确保零类型错误。代码风格检查运行Linter如ESLint。测试套件运行运行所有相关单元测试和集成测试确保通过。可访问性规则检查如果配置了相关插件如eslint-plugin-jsx-a11y进行自动检测。CI模拟运行与持续集成环境相同的构建和测试命令。任何一项检查失败都必须在此阶段修复。AI不应该也绝不允许将一个已知存在基础质量问题的变更提交评审。这就像工厂的质检环节不合格品不会流到下一条流水线。3.5 第五阶段评审Review—— 聚焦于决策与权衡经过Verify的代码其语法正确性和基础合规性已有保障。因此人工代码评审无论是自我评审还是同伴评审就可以从繁琐的“找语法错误”、“检查缩进”中解放出来聚焦于真正需要人类智慧的地方具体操作指令/cmd-review评审阶段关注的是设计决策与权衡为什么选择方案A而不是方案B这个折中考虑了哪些因素未来影响这个改动会对系统的其他部分或未来扩展产生什么潜在影响待办事项在实现过程中发现但属于当前任务范围外的问题被明确记录为“延迟观察项”而不是悄悄塞进本次修改。需要签核的项哪些决策需要更高级别或更广泛团队的知晓与同意。这个阶段的输出常常是更新架构文档 (ARCHITECTURE.md) 中的“关键讨论点”部分记录下重要的设计决策及其上下文。这极大地减轻了未来的“考古”成本。4. 实战推演以“战舰游戏CLI运行器”为例理论说了这么多我们来看一个从我真实项目一个React TypeScript战舰游戏中截取的任务实例。目标是为已有的纯逻辑游戏引擎创建一个命令行界面(CLI)运行器。核心约束游戏引擎层是纯粹的(state, action) newState函数没有任何React依赖。CLI必须能直接消费这个引擎使用完全相同的reducer、服务和类型且不允许修改任何现有领域代码。这是对架构边界是否真实的终极测试。以下就是交给AI的完整任务提示文档。请注意它不仅仅描述了“要做什么”更嵌入了工作流的执行指令# 任务实现CLI运行器 **上下文** 引擎层是纯函数状态动作 新状态无React依赖。终端运行器应直接消费它——相同的reducer、相同的服务、相同的类型——且对现有代码零修改。这将验证分层边界是真实存在的。 **事前决策不得重新讨论** - src/cli/ 目录下任何地方不允许出现React导入。 - CLI中不包含游戏规则——只有I/O、渲染和驱动引擎。 - LineReader 接口抽象Node的readline避免在vite/client类型作用域下导入Node类型。 - 无颜色、无ANSI格式化、无AI射击延迟——终端输出是同步的延迟无意义。 - 无布置战舰阶段——两种模式都使用 generateRandomLayout。 - 不为 src/cli/ 编写测试——所有有意义的逻辑都已被引擎和服务测试覆盖。 **待创建文件4个** - src/cli/index.ts —— 入口点模式和难度菜单readline生命周期循环。 - src/cli/loop.ts —— 单人模式和对抗电脑模式的游戏循环。 - src/cli/renderer.ts —— 纯字符串渲染棋盘网格射击结果游戏结束信息。 - src/cli/input.ts —— 坐标解析器readline提示循环LineReader接口。 **待修改文件2个** - tsconfig.cli.json —— 确认CLI入口点配置正确。 - docs/ARCHITECTURE.md —— 新增CLI章节记录消费者模式及AI延迟的故意省略。 **类型** - input.ts 中的 LineReader 接口{ question(prompt: string, cb: (answer: string) void): void; close(): void } —— 抽象readline无需导入Node类型。 - 无新的领域类型——全部使用来自 engine/、services/、types/ 的现有类型。 **函数** - renderBoard(boardState: BoardState, label: string): string —— 纯字符串函数无副作用可单元测试。 - parseCoordinateInput(input: string, boardSize: number): Coordinate | null —— 纯函数输入无效时返回null。 - runSinglePlayerLoop(rl: LineReader, difficulty: Difficulty): Promisevoid —— 异步直接驱动引擎reducer。 - runVsComputerLoop(rl: LineReader, difficulty: Difficulty): Promisevoid —— 异步相同模式。 **状态** - 无新状态。CLI将引擎reducer作为普通函数驱动state reducer(state, action)。 **可访问性影响**无——仅限终端。 **必需的AI工作流** 1. /cmd-preflight —— 通读 CLAUDE.md搜索与本任务相关的现有引擎reducer、服务函数和类型。确认 src/cli/ 尚不存在。运行 npx tsc -p tsconfig.json --noEmit、npm test、npm run lint。如有任何失败不得继续。 2. /cmd-plan —— 生成完整的实现计划涵盖类型、函数签名、文件列表及 ARCHITECTURE.md 更新。在获得明确批准前不得编写任何代码。 3. /cmd-implement —— 按此顺序实现input.ts、renderer.ts、loop.ts、index.ts然后更新 docs/ARCHITECTURE.md。一次完成一个文件。禁止范围蔓延。 4. /cmd-verify —— 确认 src/cli/ 中零React导入未从服务层重复任何领域逻辑TypeScript检查通过所有现有测试仍能通过。 5. /cmd-review —— 明确展示决策、权衡以及故意省略AI延迟的原因。标记任何需要签字确认的事项。 **风险标识** - crypto.randomUUID 可能并非在所有Node版本中都可用——需确认或使用 Math.random 回退方案。 - AI射击延迟被故意省略——需明确记录以免未来阅读者将其加回。 **测试计划** - 无CLI专项测试。引擎、服务和渲染器纯函数已被现有及新增的单元测试覆盖。 - renderer.ts 和 input.ts 如需可在日后单独测试。 **验收标准** - npm run cli 可启动游戏。 - 单人模式和对抗电脑模式均可端到端运行。 - 难度选择功能正常。 - 射击输入解析正确对无效输入给出提示信息。 - 能检测并报告游戏结束。 - 对 engine/、services/、utils/、types/、constants/ 的修改为零。 - src/cli/ 目录中无任何React导入。 - docs/ARCHITECTURE.md 已更新CLI章节。 **禁止事项** - 禁止在 src/cli/ 的任何地方导入React。 - 禁止从 services/ 重复任何规则逻辑。 - 禁止添加AI射击延迟。 - 禁止添加布置阶段。 - 禁止提交——在评审批准后即停止。这份文档就是开发前的“宪法”。AI将严格依据它来执行。最终产出的会是一个单一、可评审、目的明确的提交而不是一个包含40个文件、毫无清晰叙事的巨大差异对比。原子化的提示产生原子化的提交。Git历史保持可读代码评审保持可管理。这不是工作流的副作用而是在动代码之前就定义好范围所带来的结构性成果。5. 支撑系统编码知识库与领域技能工作流的命令序列只是触发器真正赋予其力量的是背后的约束系统——即编码化的团队知识与领域规则。没有这个工作流就只是一套提示词模式有了它才是一个完整的工程系统。在我的项目中这体现为两个层面CLAUDE.md工程标准文档这是一个活的文档定义了所有架构层面的“宪法”。例如分层契约严格定义引擎层、服务层、工具层、UI层之间的依赖方向和数据流。比如“引擎层不得导入任何UI框架相关模块”。状态设计规则规定哪些状态是可变的、哪些是只读的、状态更新的唯一路径是什么。坐标处理规范所有棋盘坐标必须使用{ row: number; col: number }对象禁止使用数组或字符串拼接等临时表示。TypeScript配置开启strict: true禁止使用any必须为函数返回值显式定义类型等。可访问性规则所有交互式组件必须可通过键盘操作图片必须有alt文本等。测试策略纯函数必须单元测试组件测试使用Testing Library集成测试覆盖核心用户流程。领域技能库.claude/skills/这是一系列针对特定领域知识的编码文件AI在相关上下文会自动加载。例如react-architecture.md包含React项目分层的最佳实践、状态提升与下放的判断逻辑、自定义Hook的编写规范。wcag-react.md针对React的具体可访问性实现模式如表单标签关联、焦点管理、ARIA属性使用示例。vitest-react.md定义如何使用Vitest和React Testing Library编写测试包括Mock策略和渲染辅助函数。这套系统的威力在于它让AI不必在每次会话中重新“发现”或“猜测”团队规则。规则被白纸黑字地写下来进行版本控制并且每次任务都可用。这极大地减少了沟通开销和上下文切换成本确保了输出的一致性。工程师不再需要反复口述“我们这里规定要……”只需要说“请遵循CLAUDE.md和react-architecture技能”。6. 常见陷阱与心智模型调整即使理解了工作流在实际推行中也会遇到阻力。以下是一些常见的陷阱及应对策略陷阱一“这太慢了不如直接开干。”错觉跳过前期思考似乎更快。现实在复杂项目中因前期理解偏差导致的返工、调试和沟通成本远超前期投入的思考时间。工作流强制进行的“慢思考”实际上是通过降低返工率来提升整体速度。第一个任务可能最“费时”但第五十个任务会因此变得流畅而清晰。陷阱二“AI能自己搞定我只需要审核代码。”风险沦为被动的代码审核者将设计主动权让渡给AI。正确姿势你必须是设计的主导者。AI是执行者。Preflight和Plan阶段是你输出设计意图、让AI对齐的过程。你的价值体现在提出正确的问题、识别AI方案中的潜在缺陷、做出关键的架构权衡。陷阱三约束文档如CLAUDE.md变成一纸空文。问题制定了规则但执行不严格逐渐失效。解决方案将规则验证自动化。在Verify阶段通过脚本或工具如自定义ESLint规则、架构依赖关系检查工具自动检查是否违反CLAUDE.md中的关键约束。让机器来守护规则。陷阱四过度设计陷入“分析瘫痪”。平衡点工作流不是鼓励无休止的设计。Preflight和Plan阶段应该有明确的时间盒。目标是产出“足够好、可演进”的设计而不是“完美无缺、涵盖一切”的设计。关键在于识别出那些一旦错误代价高昂的决策如核心数据模型、系统边界在这些地方投入精力对于那些容易修改的细节可以适当放宽。陷阱五忽略了知识库的维护。关键CLAUDE.md和技能库不是静态的。随着项目演进和技术栈更新它们也需要迭代。建立一个轻量级的流程当团队遇到重复性的设计决策或发现新的最佳实践时将其总结并更新到知识库中。这本身就是一种宝贵的技术资产管理。7. 工具之外的思考回归工程的本源最后我想分享一个可能有些反潮流的观点AI工具并没有赋予你原本不具备的判断力它只是给了你时间去运用你已有的判断力。对于那些早已在思考架构、但总是被deadline追着跑、没有“跑道”去实践的工程师来说这是一个真正意义上的解放。时间这个最大的约束消失了。你可以像下棋一样先看三步再落子。但对于那些原本就习惯于“先行动、后思考”的团队或个人AI带来的可能只是“更快的错误产出”。区别会在六个月后显现一个代码库仍然可以清晰、干净地扩展另一个则变成了需要专人“考古”才能理解的废墟。“战舰”项目对我而言其目标从来不是构建一个游戏。它是一个载体用于演示当你有时间在写代码之前进行思考时一个具有纪律性的前端架构会是什么样子。最有力的证明不是React UI本身而是那个不依赖任何前端框架、直接消费同一套引擎逻辑的CLI运行器。而更有说服力的产物是那份docs/ARCHITECTURE.md文档它解释了代码库中每一个重要决策、每一个被考虑的替代方案以及选择背后的理由。这份文档在通常的工期压力下是写不出来的。不是因为工程师能力不足而是因为没有时间。约束从来不是知识而是时间。现在这个约束在很大程度上已经消失了。我们是否准备好将这份被归还的时间真正投入到那些决定系统长期生存能力的工作中去这才是AI带给软件工程最深远的挑战与机遇。
![原神帧率解锁终极指南：5分钟突破60帧限制的完整教程 [特殊字符]](http://pic.xiahunao.cn/yaotu/原神帧率解锁终极指南：5分钟突破60帧限制的完整教程 [特殊字符])
