本文源于幂律技术团队25年11月的内部技术分享。这是我们在打造AI Native法律科技产品的过程中，对新一代研发模式的沉淀与思考，与各位分享。

本次分享旨在探讨如何高效利用以Cursor、Claude Code为代表的AI原生开发工具，深度结合大语言模型（Large Language Model, LLM）赋能软件工程的日常开发。我们的目标是在显著提升开发效率的同时，确保代码质量达到甚至超越传统人工开发的标准。

软件开发工作的解构与分析

为了系统性地应用LLM，我们将开发任务从两个维度进行考量：

• 宽度：指代业务逻辑的广度与复杂度。

• 深度：指代技术设计的抽象层次，或任务所需拆解的层级数量。

对于深度与宽度适中的任务，顶尖的LLM已能提供稳定且高质量的输出。当任务的宽度或深度超出模型的直接处理能力时，挑战依然存在；然而，若能将复杂任务有效拆解为一系列深度与宽度均在可控范围内的子任务，LLM依旧能成为我们强大的助手。

基于此，我们将开发任务划分为两类：

• 第一类任务：粒度精细、步骤单一、目标明确的任务。此类任务通常无需复杂的前置设计，可直接进入实现阶段。

  • 示例："为搜索框增加移动端适配：默认仅显示搜索图标，点击后展开为输入框"、" 为 UserService 类编写完整的单元测试 "。

• 第二类任务：复杂度超越第一类任务，需要进行系统性设计与规划的复合型任务。

  • 示例："为公司的集成平台增加 MySQL 持久化支持"。

这种任务分类方式，借鉴了丹尼尔・卡尼曼在《思考，快与慢》中提出的 “系统一” 与 “系统二” 思维模型。第一类任务如同依赖直觉和经验的 “快思考”，而第二类任务则需要深思熟虑、审慎规划的 “慢思考”。

01、第一类任务：上下文决定成败

对于第一类任务，LLM能否胜任？答案是肯定的，但其关键前提是：高质量的上下文。

我们必须引入并重视“上下文工程” (Context Engineering) 的概念。在当前技术阶段，上下文的质量是决定LLM输出质量的首要因素，其重要性甚至超过了模型能力本身。

为了避免额外引入 Agent 的概念，此文中我们将上下文定义为"解决任务的必要信息"与"和环境交互的能力"的集合。

• 必要信息：直接决定了LLM输出的准确性与相关性。

• 环境交互：使LLM能将输出应用于实际环境，并作为获取更多信息的关键手段。

因此，当LLM的输出未达预期时，我们应首先分析是否提供了充分、准确的上下文。这也是为何我们认为，像MeFlow3这类AI Native产品能够提供持续且不可替代的价值。

总结而言，只要提供了充足的上下文，LLM基本能够高质量地完成第一类任务。因此，高效完成第一类任务的核心，在于如何为大模型提供高质量的上下文。

02、第二类任务：拆解是关键

那么，大模型能否有效处理第二类任务？这个问题远比第一类任务复杂，答案并非简单的 “是” 或 “否”。

在无任何外部辅助的情况下，顶尖的LLM也能在一定深度和宽度范围内自主完成某些第二类任务。同时，诸如Cursor、Claude Code等现代AI编程工具，通过内置的任务规划和上下文管理能力，进一步拓展了LLM独立完成任务的边界。

然而，更通用、更可控的方法是将一个第二类任务系统性地拆解为一系列第一类任务。这种拆解可以通过多种方式实现：

1. 隐式拆分：对于能力较强的模型，我们仅需提供一个高层次的计划或步骤清单作为上下文，模型便能自行规划并逐步执行。这类似于为其提供一个序贯思考（Sequential Thinking）的框架。

2. 显式拆分：对于能力较弱的模型或极其复杂的任务，我们需要借助n8n、Coze等流程编排工具，或通过人工干预，来强制定义任务的执行步骤。

值得注意的是，任务拆分的过程，其本身也是明确需求规格（Specification）和完善上下文的过程。一个模糊的、一句话的需求描述，往往隐藏着大量未明确的细节，而拆分正是将这些细节具体化的过程。

我们的核心工作：新范式下的工程师职责

综上所述，在 AI 辅助开发的新范式下，工程师的核心职责将收敛于两点：

1. 提供精准且充分的上下文。

2. 对复杂任务进行有效的拆解。

如何高效提供上下文

提供上下文的方法可分为“即时策略”与“长效机制”。我们的目标不仅是单次有效地提供上下文，更要持续降低提供上下文的成本。

1.即时策略：高效提供单词任务上下文

善用工具的原生能力

积极拥抱并熟练使用现代AI编程工具。它们已经解决了大部分上下文获取问题，并内置了强大的环境交互能力。对于许多任务，我们无需进行繁琐的上下文工程，工具已为我们铺平道路。

示例：利用Claude Code的命令行交互能力

Cursor和Claude Code等工具能够直接运行命令行并理解其输出，这赋予了它们强大的信息获取和环境交互能力。当命令执行失败时，我们无需详细描述错误，只需将问题抛给模型即可。

Prompt 示例： “我的 [某个命令] 突然运行失败了，请帮我排查问题。”

主动提供关键信息

当工具无法自动获取某些特定上下文时，主动提供信息是最高效的补充方式。

示例：提供 API 定义以创建新工具

Prompt 示例： “请参考 @dataitem_tools.py 的实现，为我添加两个新工具：1. 获取评审流程信息；2. 获取评论列表。相关的 cURL 请求示例如下：[此处粘贴两个 cURL 示例]”

提炼与复用规则 (重要)

让LLM基于一个或多个实现样例，自行归纳总结该类型任务的实现模式或最佳实践，并将其整理为可复用的规则（如 Cursor 的 cursorrule）。这能将成功的实践标准化，作为未来同类任务的核心上下文。

示例 1：根据现有代码，总结cursorrule

首次为某类任务创建规则时，只需提供参考文件和简单的任务描述。

Prompt 示例： “请帮我整理一份‘新增流程引擎节点类型’的标准开发文档。节点接口定义请参考 @Node.java，具体实现可参考 @nodes/ 目录下的所有实现。这份文档将作为未来新增节点类型的标准指南，供开发人员和 LLM 使用。”

后续使用

Prompt 示例： “@flowengine_node.mdc。请帮我实现一个电子签节点。当流程运行至此节点时，调用 xxx 函数对接外部电子签平台。”

示例 2：根据对话，迭代更新cursorrule

在使用规则的过程中，我们可能会发现某些边界条件或特定问题未被覆盖。在手动编码修正后，可以让 LLM 自动将这些改进更新回规则文档中。

Prompt 示例：“请回顾本次对话中我提供的所有代码和说明，检查 @some_cursor_rule.mdc 中有哪些未覆盖到或有偏差的点，然后帮我更新这份规则文档。”

引导模型自主探索上下文

在某些场景下，我们无法预先知道完成任务需要哪些确切信息，或者明确这些信息本身就是工作的主要部分。此时，我们可以授权LLM自行探索，从而明确上下文。

示例 1：编写操作手册 - Playwright MCP

编写图文并茂的操作手册，其核心工作是梳理操作步骤。我们可以让 LLM 自行探索并记录这些步骤。

Prompt 示例： “请在 @guides/ 目录下为我撰写一篇‘如何创建触发器’的操作手册。你需要先使用 Playwright MCP 打开 https://xxxxx.com 实际操作一遍，然后整理出详细的图文步骤。注意浏览器尺寸保持 4:3 的小尺寸比例。创建成功后，记得为触发器添加一个 dataItemId = contract 的筛选条件。”

应对上下文的时效性问题

当使用的技术栈较新，超出了LLM的训练数据范围时，直接提问往往效果不佳。此时，我们可以明确指示LLM先通过Context7 MCP搜索并阅读最新的官方文档，再执行任务。

Prompt 示例： “请帮我用 [某项新技术] 实现 xxxx 功能。在开始编码前，请先使用 Context7 MCP 搜索并阅读相关的官方文档。”

2.长效机制：构建对AI友好的架构

一个对LLM开发友好的架构，本质上也是一个对人类开发友好的架构。

持续优化与重构

LLM在生成功能代码时，若无明确指令，通常不会过多关注代码的可维护性与复用性，可能产出长函数、长文件等。因此，在模型完成初步开发后，我们应明确要求其进行代码优化，如函数拆分、文件整理、抽象封装等。

同时，定期对代码库进行整体结构分析与重构，能确保项目在业务发展中持续保持健康状态。

在大模型的帮助下，这类重构工作的成本远低于纯人工操作。

坚持高内聚、低耦合

无论是LLM辅助开发还是传统开发，高内聚、低耦合始终是衡量代码质量的核心标准。良好的架构设计（如模块化、清晰的接口定义）是确保单个任务所需上下文在可控范围内的关键。若忽视架构，项目耦合度会急剧上升，导致任何微小的改动都可能 “牵一发而动全身”，最终使维护成本变得无法承受。

对于LLM而言，在一个设计不良的项目中，实现一个小功能可能需要修改十几个文件，这种上下文宽度超出了其处理能力的上限（对人类开发者亦是如此）。因此，在下达开发指令时，我们不仅要提供业务功能上下文，更要明确架构设计要求，尤其是模块化和解耦的原则；这一步骤也通常包含在下一章中提到的 “任务规划” 的过程中。

在保障了高内聚低耦合的架构设计之后，后续LLM在实现具体的功能时，我们就可以利用上述具体方法（即时）中提到的诸多方法来为LLM提供有效的功能spec和上下文，高效高质量的完成相关的开发工作。

加强文档建设

维护高质量的文档（包括 cursorrule 这类规则文档）是提供非代码类上下文的重要维度，其价值不容忽视。

如何有效进行任务拆分

"规划 - 确认 - 执行" 模式

在处理单个第二类任务时，"规划 - 确认 - 执行" (Plan-Confirm-Execute) 是核心模式。

对于任何复杂的第二类任务，都应首先让LLM提供设计思路和执行计划。在执行前进行人工确认，这样做的好处是双重的：

1. 明确任务细节：复杂任务的上下文难以一次性给全。LLM生成详细计划的过程，本身就是暴露和澄清模糊需求点的过程。

2. 修正方向偏差：LLM的规划未必总是最优或完全正确。在执行前审查并修正其规划，可以避免后续的无效工作和资源浪费。

确认环节的关键审查点：

• 方向对齐：LLM对任务的整体理解、设计思路是否与预期一致？方向性偏差必须在第一时间纠正。

• 子任务准确性：模型拆解出的子任务是否合理、可执行？我们需要对模型基于推测得出的细节进行确认。

• 架构合规性：模型提出的实现架构是否符合我们预设的规范（如高内聚、低耦合原则）？

Cursor等工具的plan模式天然支持此流程。对于中等复杂度的任务，通过简单的Prompt让LLM先出方案再执行，也是一种有效的实践。

采用增量式开发策略

先实现核心功能与基础架构，然后迭代式地进行优化（性能、边界情况、错误处理），最后再补充完善（文档、测试）。这种开发方式天然地将一个大任务分解为一系列有序、可管理的子任务。

大模型时代，开发者的角色演进与应对策略

知识价值的转变

• "记忆型" 知识贬值：对特定框架、API的记忆和掌握程度，其价值大幅降低。例如，记住某个CSS属性的具体写法价值很低，但理解CSS的盒模型、Flexbox布局原理的价值依旧很高。

  • 策略：深入学习每种技术栈中的一个代表，理解其底层的设计哲学和工作原理。其余的，交给LLM。

• "原理型" 知识增值：底层设计逻辑、设计模式、系统原理等通用知识的重要性空前提高。

• "架构型" 能力成为核心：保证代码质量和系统可维护性的架构设计能力，正成为工程师的核心竞争力。

必备的心态与习惯

• 保持积极开放的心态：新技术必然伴随不完美，但我们应关注其带来的颠覆性价值，而不是因噎废食。

• 校准对LLM能力的认知：

  • 如何衡量使用程度？一个可供参考的启发式指标：如果日常工作70%是代码开发，且使用Claude Sonnet 4.5级别和费用的模型，那么在Cursor这类工具中，每月账单额度应不低于200美元。对应到GLM 4.6的模型价格，大概不到200人民币的模型费用。

  • 把握工具和模型的能力边界：准确判断哪些任务的输出是高度可信的（如生成样板代码、格式转换），哪些是需要仔细审查的（如复杂的业务逻辑、安全相关的代码）。

• 仍需保持对代码仓库的掌握：对于关键的架构和底层原理，仍需保持对代码仓库的掌握，以确保在需要时能够进行深入的代码审查和优化。但是同时也要能判断出，何种具体功能和代码可以作为一个黑盒交由大模型处理。

结语

在AI辅助开发的新浪潮中，工程师的角色正在从代码的直接“生产者”转变为“指挥者”和“质量保证者”。我们的核心工作是进行高质量的思考、拆解、规划和验证，将我们的智慧与 LLM 强大的执行力相结合。拥抱这一转变，我们将能在创造更高价值的同时，享受更富创造力和影响力的工程工作。

💡附录：本篇文章的写作过程

1. 发散思考：整理个人在大模型辅助开发过程中的经验、判断与认识。

2. 梳理思路：对文章的叙述结构进行顶层设计。

3. 构建大纲：整理文章的核心大纲，并填充关键内容，形成文章草稿。

4. 内容增强：将草稿提供给 LLM，让其搜索互联网上的相关主题文章，并提出内容补充建议。

5. 整合优化：结合 LLM 的建议调整核心文章，并交由 LLM 进行语言润色和结构优化，生成最终版本。（本次润色使用了 Gemini 2.5 Pro，其在技术文章风格的把握上表现出色）

6. 最终审阅：对 LLM 生成的文章进行人工审阅，并对有偏差的内容进行微调。

招聘信息

👋 写在最后：来和我们一起把「新范式」变成日常

如果你读完这篇文章，不仅没有产生“AI 会取代程序员”的焦虑，反而对文中提到的“上下文工程”、“任务拆解”以及“人机协作”感到兴奋——那么，你就是我们在找的人。

我们是 幂律产研团队。 正如文中所述，我们不只是在构建一款智能合同管理产品，我们更是在践行一种 AI Native 的研发文化。

在这里，我们拒绝机械地堆砌代码，我们寻找的是能驾驭AI工具、懂得架构设计、愿意做“指挥者”的工程师。我们正在招募Python、Java、Golang和React伙伴，共同打造真正的 AI-Native 产品。

我们需要这样的队友：

• 🐍 Python 工程师（AI 应用 / Agent 方向）：你将负责 MeFlow 核心智能业务流的实现。 这不是简单的脚本编写，你需要将文章中提到的“复杂任务拆解”和“系统二（慢思考）”逻辑，转化为产品中可运行的代码。你将利用 Python 生态和 Agent 技术，让 MeFlow 能够真正“理解”合同业务，实现从意图识别到自动执行的完整闭环。

• ☕️ 后端工程师（Java）：你不需要默写所有语法，但你必须懂得“高内聚、低耦合”。 我们需要你构建对 LLM 友好的领域模型与系统架构。你需要确保系统的接口定义清晰、数据结构稳健，为 AI 能够准确获取“上下文”和进行“环境交互”提供最坚实的底座。

• 🐹 Golang 工程师（Agent 集成平台）：你将负责构建高性能的 Agent 集成与调度平台。 Agent 需要与外部世界大量交互，我们需要你构建高并发、高稳定的集成通道。你将利用 Go 语言的特性，解决异构系统对接、实时数据流处理等挑战，为智能体提供敏捷可靠的“手脚”，确保 Agent 的指令能被精准送达与执行。

• ⚛️ 前端工程师 (TypeScript + React)：你不仅关注界面美观，更关注“人机协作逻辑”。 我们需要你思考 AI 时代的交互形态——如何让用户更自然地向 Agent 传达意图？如何优雅地展示 Agent 的思考路径？你需要利用 Cursor 等工具高效产出，打造“所想即所得”的流畅体验。

在幂律，你将获得：

• 知行合一的环境：文章里写的上下文工程、规则提炼，就是我们每天真实的工作方式。

• 拒绝无效内卷：我们用工具提升效率，把时间花在更有价值的架构设计与业务思考上。

• 极客氛围：如果你也喜欢折腾 Cursor、Claude Code 等，或者写过自己的 cursorrule、CLAUDE.md，那我们会有很多共同语言。

如果你想在 AI 时代，做一名“更有创造力”的工程师，欢迎加入我们。

📮 简历请投递至：zhaoshichang@powerlaw.ai（备注：来自微信公众号），工作地点：北京 or 成都