8.0
热点
AI SCORE
编程提效2026-08-07 00:40
如何按任务特征选择AI开发模式
dev.to · AI#AI编程#Agent#工作流
Editor brief · 编辑速览
文章用“端到端新增筛选器”对比AI助手、边界上下文开发和自主智能体三种工作流。核心判断依据是方案是否明确、实现流程是否稳定以及项目现有基础设施是否完善。
越常规、对开发者成长帮助越小的任务，投入的开发者精力就应该越少。
在上一篇文章中，我介绍了 AI Bounded-Context Development（AI 边界上下文开发，简称 AB-CD）：在这种工作流中，开发者确定预期方案，控制每个实现步骤的信息边界，并将大量底层实现工作委派给 LLM。
但 AB-CD 并不适合所有任务。
有时，解决方案本身仍有待探索。另一些时候，解决方案和实现流程都足够稳定，可以进行更大范围的委派。
这一次，我想通过一个真实的功能需求，展示它在工程上的不同形态，如何影响我们在 AI-as-a-Helper、AB-CD 和 Agentic AI 之间做出选择。
这个任务听起来很简单：
添加一个贯穿端到端流程的新过滤器。
但仅凭这句话，还不足以选择 AI 工作流。
这个过滤器是否与现有过滤器几乎完全相同？
它是否引入了新的交互模式、数据类型或数据库需求？
还是说，这个项目根本没有过滤基础设施？
这些任务都可以被描述为“添加一个过滤器”，但从工程角度看，它们有着本质区别。
从任务出发，而不是从你最喜欢的 AI 工具出发。
下面的代码示例经过了精简和匿名化处理。这里的目的不是把这种架构包装成普遍正确的方案，而是展示：对真实代码库的了解，会如何影响工作流决策。
这是一个教育类创业项目。相关代码属于 Filter-Sort-Paginate 模块，其核心实体是用户创建的摘要。
技术栈：ASP.NET Web API、C#、OpenAPI、Angular、TypeScript、RxJS 和 ng-open-api。
左侧面板包含过滤控件。
右侧区域包含已选过滤条件的 chips，以及过滤后的摘要。
过滤条件的变化会通过共享事件中心进行广播，并由 UI 中多个彼此独立的部分消费。因此，添加一个过滤器并不是局部修改表单这么简单。
从宏观上看，数据流如下：
Filter control
→ shared filter state
→ chips synchronization
→ API request contract
→ backend filtering pipeline
任务是让一个新的过滤器贯穿整个流程。
我暂时刻意不说明具体要添加哪一种过滤器，因为这个缺失的细节恰恰决定了应该选择哪种工作流。
在选择工作流之前，开发者需要对任务有足够的理解，能够回答以下四个问题：
预期方案是否已经明确？
实现路径是否稳定？
是否可以有把握地定义信息边界？
是否已经存在可复用的流程？
在这个项目中，初步筛选大约花了五到十分钟，因为我已经非常熟悉这个代码库。
Angular 过滤组件既会恢复外部状态，也会发布用户所做的修改：
export class SumsFilterComponent implements OnInit {
private _reactOnInputTechDataChanged() {
this._sumsFilterBhub.selectedDataInputChanged
.react()
.subscribe((selectedDataInput) => {
this._updateForm(selectedDataInput);
});
}
private _reactOnFormValueChange() {
this.form.valueChanges.subscribe((formValue) => {
this._sumsFilterBhub.selectedDataOutputChanged.trigger(
formValue as SumsFilterSelectedData,
);
});
}
}
新过滤器必须同时参与这两个方向的数据流。只在模板中添加一个控件，会导致整个状态流不完整。
同一份状态还会被 chips 模块消费，并转换为自动生成的 API 请求参数，最终由后端过滤管线应用：
if (fpsParams.FilterStarred.HasValue)
{
query = query.Where(
summary =>
fpsParams.FilterStarred.Value
? summary.IsStarred
: !summary.IsStarred
);
}
自动生成的前端 API contract 不应手动编辑。
新过滤器是应该直接放进现有后端方法，还是需要独立的查询服务，抑或需要修改数据库，取决于它的语义。
到这里，贯穿整个应用的实现路径已经清晰可见。剩下的问题是：我们要添加的究竟是哪一种过滤器？
假设需求是：
参照现有的 starred 过滤器，添加一个 boolean 过滤器。
它的预期行为、受影响的层、状态结构、chips 生命周期、API 映射、后端 predicate，以及可能采用的测试结构，都已经明确。
这主要是一个复制既有模式的任务。
第一次实现时，我会使用 AB-CD，把隐含的流程显式表达出来，并通过一次真实修改验证这套流程。
当流程稳定并被记录下来后，后续的重复任务就非常适合交给 Agentic AI。
Known procedure in the developer’s head
→ express it through AB-CD
→ validate it on a real task
→ encode reusable guidance
→ delegate later repetitions to Agentic AI
一个任务可以重复，并不意味着它天然适合 Agentic AI。相应流程还必须明确、稳定且可验证。
AI-as-a-Helper 虽然能保留控制权，但会把一次可预测的端到端修改拆解成彼此孤立的片段，反而削弱整体效率。
现在假设这个过滤器并不能直接类比 starred 过滤器。
不熟悉的状态语义；
range、hierarchy 或 multi-value 结构；
不同的 API contract；
新增数据库字段或关系；
独立的后端查询。
这个应用已经具备过滤架构，受影响的各个层也已经明确。
尚未确定的是：在现有架构内部，正确的行为应该是什么。
对于这种情况，我会把 AB-CD 作为主要的实现工作流。
AI-as-a-Helper 委派得太少，因为大部分集成路径已经明确。
Agentic AI 委派得太多，因为其中的重要工程决策还无法编码成稳定流程。
一个具体的循环可能如下：
1. The developer decides that the filter is a nullable date range.
2. The developer defines its form, chips, API, and backend semantics.
3. A Context Contract is created for the frontend-state step.
4. The LLM implements the step inside that boundary.
5. The developer reviews the result and clarifies empty-value behavior.
6. The boundary changes for the backend step.
7. The LLM implements the predicate and tests.
8. The API client is regenerated and the final flow is reviewed.
单个功能不必从头到尾只使用一种工作流。
AI-as-a-Helper:
investigate unfamiliar UX or architectural alternatives
AB-CD:
implement the selected solution through controlled steps
Agentic AI:
apply an established procedure to routine parts
在同一个任务的不同阶段，工作流的主导权可以发生变化。
现在假设这个项目完全没有过滤架构。
此时，任务就不再是“再添加一个过滤器”。
而是设计并实现一套过滤管线，使其能够支持多种过滤器结构，同时保持可维护性。
其中尚未确定的问题包括：
过滤状态应该存放在哪里；
各个控件应该如何与 UI 的其他部分通信；
过滤器应该如何序列化；
多个 predicate 应该如何组合；
分页、排序与过滤之间应该如何交互；
未来新增的过滤器应该如何扩展现有设计。
在这个阶段，最重要的工作不是实现。
而是确定正确的解决方案。
此时，AI-as-a-Helper 应该成为主要的推理工作流。AI 可以研究备选方案、追踪依赖关系，或者生成探索性代码，但架构的主导权仍由开发者掌握。
决定工作流的，并不是 AI 生成了多少代码，而是谁掌握决策循环。
现在使用 AB-CD 还为时过早，因为我们尚未充分理解解决方案，无法从中划分出稳定的边界。
使用 Agentic AI 则存在较高风险，因为大范围的自主实现，可能会把某个看似合理的架构变成一次意外且难以回头的承诺。
Agent 仍然可以帮助探索代码库、追踪依赖关系，以及制作一次性的概念验证。不过，它们的输出只是用于支持决策的证据，而不是决策本身的替代品。
当架构逐渐清晰后，工作流也可以随之改变：
AI-as-a-Helper
→ determine the architecture and resolve high uncertainty
AB-CD
→ implement the understood solution through controlled boundaries
Agentic AI
→ repeat a stable, explicit, and validated procedure
并非每个任务都需要经历这三个阶段。
任务并不是唯一的变量。
同一个需求，由不同的人执行时，可能应该采用不同的工作流。
我非常熟悉这个代码库，因为我就是它的架构师。我可以迅速识别哪条路径是有意设计的，哪些抽象不应被改动，以及 AI 生成的结果究竟只是“看起来合理”，还是确实正确。
如果面对一个不太熟悉的项目，我会减少委派出去的实现主导权。
AB-CD 并不取决于职位头衔，而取决于开发者能否：
识别重要的工程决策；
定义预期方案；
找出相关的信息边界；
拆解实现过程；
批判性地审查结果。
学习价值同样是相对的。
对于项目架构师来说，过滤任务可能只是常规工作；但对于第一次接触这类问题的开发者来说，它可能是一次非常有价值的设计练习。
当实现路径已经明确、结果可以可靠验证，并且任务对开发者的学习价值较低时，就应该委派更多工作。
目标并不是最大化 AI 的自主程度。
目标是把开发者的精力投入到最能创造价值的地方。
这个矩阵并不是一个评分系统。
不同标准可能会指向不同方向。
一个重复性很高但缺乏明确验证方式的任务，交给 Agent 仍然可能不安全。
一项成本很高的修改，如果运行在 sandbox 中，并且有强有力的验证机制覆盖，也仍然可以使用 Agentic AI。
一个已经充分理解的一次性任务，即使没有必要把它固化为可复用的 Agentic 流程，也仍然可以使用 AB-CD。
重点不在于记住这张表，而在于理解实现主导权为什么会发生转移。
“添加一个过滤器”并不是一种单一的工程任务。
当解决方案本身尚未确定时，开发者应该通过 AI-as-a-Helper 保留推理循环的主导权。
当预期方案已经明确，但实现过程中仍需有意识地调整时，AB-CD 就成为自然的实现工作流。
当流程稳定、明确、可重复，并且经过了充分验证时，选择 Agentic AI 就会越来越合理。
随着不确定性的降低，同一个功能可以在这些工作流之间迁移。
越常规、对开发者成长帮助越小的任务，投入的开发者精力就应该越少。
当开发者理解预期方案，希望保留决策主导权，并且能够通过受控的实现步骤和信息边界来表达这个方案时，AB-CD 最有价值。
如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。