Moyu 是一种反过度工程的 Prompt 策略,让 AI 编码助手只做该做的事。 Moyu is an anti-over-engineering prompt strategy that keeps AI coding assistants from doing more than they should.
你只想要一个简单的函数,AI 却给你写了工业级方案。 You asked for a simple function. AI gave you an industrial-grade solution.
def add(a, b):
"""
Add two numbers together.
Args:
a (int | float): The first number.
b (int | float): The second number.
Returns:
int | float: The sum of a and b.
Raises:
TypeError: If inputs are not numbers.
OverflowError: If result exceeds limits.
Examples:
>>> add(1, 2)
3
>>> add(1.5, 2.5)
4.0
"""
if not isinstance(a, (int, float)):
raise TypeError(
f"Expected number for a, got {type(a).__name__}"
)
if not isinstance(b, (int, float)):
raise TypeError(
f"Expected number for b, got {type(b).__name__}"
)
try:
result = a + b
except OverflowError:
raise OverflowError(
"Result exceeds maximum float value"
)
if isinstance(result, float) and (
math.isinf(result) or math.isnan(result)
):
raise OverflowError(
"Result is infinity or NaN"
)
return result
def add(a, b):
"""Add two numbers."""
return a + b
def test_add():
assert add(1, 2) == 3
assert add(-1, 1) == 0
三种策略,互补协作,覆盖 AI 编程的不同失败模式。 Three strategies, complementary, covering different AI coding failure modes.
"它们让 AI 不放弃。我们让 AI 不做多。" "They keep AI from giving up. We keep AI from overdoing it."
Moyu 的核心哲学,简单到可以写在便签纸上。 The core philosophy of Moyu, simple enough for a sticky note.
不要主动"改进"、"优化"或重构不相关的代码。做被要求做的,仅此而已。 Do not proactively "improve", "optimize", or refactor unrelated code. Do what was asked, nothing more.
能用 3 行解决就不要用 30 行。避免不必要的抽象、设计模式和类型体操。 If 3 lines work, don't write 30. Avoid unnecessary abstractions, design patterns, and type gymnastics.
与其猜测需求然后过度实现,不如直接问清楚。沟通优于假设。 Instead of guessing requirements and over-implementing, just ask. Communication beats assumption.
3 个模型 x 5 种条件 x 12 个场景 x 3 次试验 = 540 次实验 3 Models x 5 Conditions x 12 Scenarios x 3 Trials = 540 Experiments
| 条件 | Condition | 描述 | Description |
|---|---|---|---|
| Control | 无 system prompt | No system prompt | |
| Baseline-Concise | "请简洁" | "Be concise" | |
| Moyu-Lite | Moyu 精简版 | Moyu Lite variant | |
| Moyu-Standard | Moyu 标准版 | Moyu Standard | |
| Moyu-Strict | Moyu 严格版 | Moyu Strict variant |
| ID | 类型 | Type | 描述 | Description |
|---|---|---|---|---|
| S1 | A | 修复 complete_task 空指针 bug | Fix complete_task null pointer bug | |
| S2 | A | 添加 list_tasks_sorted 函数 | Add list_tasks_sorted function | |
| S3 | A | 给 search 加 status 参数 | Add status param to search | |
| S4 | A | 添加 export_csv 函数 | Add export_csv function | |
| S5 | A | 给 list_tasks 加 assignee 筛选 | Add assignee filter to list_tasks | |
| S6 | A | 添加 bulk_complete 函数 | Add bulk_complete function | |
| S7 | A | 修复 delete_task 返回值 | Fix delete_task return value | |
| S8 | A | 添加 get_tasks_by_assignee | Add get_tasks_by_assignee | |
| S9 | B | 重构为 context manager | Refactor to context managers | |
| S10 | B | 添加 docstring | Add docstrings | |
| S11 | B | 编写单元测试 | Write unit tests | |
| S12 | C | 修复 bug + 新功能 | Fix bug + new feature |
A = 过度工程高发区 (应缩减), B = 用户显式请求 (不应抑制), C = 混合 A = Over-engineering hotspots (should reduce), B = Explicit user requests (should NOT suppress), C = Mixed
| 模型 | Model | 提供商 | Provider |
|---|---|---|---|
| Claude Sonnet 4 | Anthropic | ||
| GPT-4o | OpenAI | ||
| Gemini 2.5 Pro |
| 指标 | Metric | 描述 | Description |
|---|---|---|---|
| LOC | 代码行数(不含空行和注释) | Lines of code (excl. blanks/comments) | |
| OE Score | 过度工程评分(0-10) | Over-engineering score (0-10) | |
| Correctness | 功能正确性(通过测试比例) | Functional correctness (test pass rate) | |
| OE Signals | 过度工程信号分解 | Over-engineering signal decomposition |
Moyu-Standard 将 A 类场景代码行数减少约 —%,过度工程信号下降 —%,同时保持 —% 功能正确率。 Moyu-Standard reduced A-type scenario LOC by ~—%, OE signals down —%, while maintaining —% correctness.
"写简洁点" vs Moyu 策略 / Lite vs Standard vs Strict / B 类任务表现 "Be concise" vs Moyu strategy / Lite vs Standard vs Strict / B-type task results
简单的 "请写简洁" 提示确实能减少代码量,但效果远不如 Moyu。Baseline-Concise 条件平均减少 LOC 约 15-20%,而 Moyu-Standard 达到了更显著的减少。更关键的是,"简洁" 提示主要减少了注释和文档,而非过度工程行为本身。 A simple "be concise" prompt does reduce code volume, but far less effectively than Moyu. The Baseline-Concise condition reduced LOC by roughly 15-20%, while Moyu-Standard achieved significantly more. Crucially, the "concise" prompt mainly reduced comments and documentation, not the over-engineering behavior itself.
Moyu-Lite 提供了基础的过度工程抑制;Standard 在 LOC 减少和正确性之间取得了最佳平衡;Strict 进一步压缩代码,但在复杂场景 (C 类) 中偶尔出现功能遗漏。 Moyu-Lite provides basic over-engineering suppression; Standard strikes the best balance between LOC reduction and correctness; Strict compresses further but occasionally misses functionality in complex (Type C) scenarios.
本研究的场景设计偏向于独立的代码修改任务,大型项目中的长对话场景需要进一步研究。此外,过度工程的定义本身具有主观性,不同团队和项目可能有不同标准。 The study's scenarios lean towards isolated code modification tasks; long-conversation scenarios in large projects require further investigation. Additionally, the definition of over-engineering is inherently subjective, with different teams and projects potentially having different standards.
Moyu 证明了一种简单的、基于规则的 Prompt 策略可以有效地抑制 AI 编码助手的过度工程行为。它不需要模型微调,不依赖特定工具链,可以无缝集成到任何开发工作流中。少即是多 -- 有时,最好的代码就是没有写出来的代码。 Moyu demonstrates that a simple, rule-based prompt strategy can effectively suppress over-engineering behavior in AI coding assistants. It requires no model fine-tuning, depends on no specific toolchain, and integrates seamlessly into any development workflow. Less is more -- sometimes the best code is the code that was never written.