我如何构建软件: 让它发挥作用, 让它漂亮, 锁住它 (中文 (Chinese Simplified))

为什么我最后写测试, 为什么这不是你所想的意思

**具有争议的取舍 :**测试驱动开发是一种绝佳的做法,它解决了最有创意的工作的错误问题。

这是更好的方法。

建筑软件的三个阶段(实际有效)

这就是我如何构建软件。

让TDD净化者礼貌地草草地翻眉毛:

让它发挥作用。弄漂亮点用测试来锁定它

graph TB
    Start[New Feature Request] --> P1[Phase 1: Make It Work]

    P1 --> P1_Private[Private Exploration]
    P1_Private --> P1_Sketch["Sketch the solution<br/>Messy code OK<br/>No tests yet<br/>Focus on learning"]
    P1_Sketch --> P1_Run["Run it manually<br/>Try different inputs<br/>See what breaks<br/>Understand the problem"]
    P1_Run --> P1_Decision{Does it work<br/>basically?}
    P1_Decision -->|No| P1_Iterate[Try different approach]
    P1_Iterate --> P1_Sketch
    P1_Decision -->|Yes| P2

    P2[Phase 2: Make It Pretty] --> P2_Refine[Private Refinement]
    P2_Refine --> P2_Clean["Clean up the code<br/>Better names<br/>Type hints/annotations<br/>Clear structure"]
    P2_Clean --> P2_Align["Align with spec<br/>Cover all requirements<br/>Handle edge cases<br/>Polish API surface"]
    P2_Align --> P2_Optimise["Optimise<br/>Performance<br/>Readability<br/>Maintainability"]
    P2_Optimise --> P3

    P3[Phase 3: Lock It Down] --> P3_Share[Public Sharing]
    P3_Share --> P3_Tests["Write comprehensive tests<br/>Full coverage<br/>Edge cases<br/>Error conditions"]
    P3_Tests --> P3_CI["CI/CD Integration<br/>Automated testing<br/>Code review<br/>Documentation"]
    P3_CI --> P3_Deploy["Ready to Share<br/>Commit to main<br/>Deploy to prod<br/>Other devs can use it"]

    P3_Deploy --> Done[Well-Tested,<br/>Well-Designed Code]

    style P1 stroke:#ff6b6b,stroke-width:3px
    style P2 stroke:#4ecdc4,stroke-width:3px
    style P3 stroke:#95e1d3,stroke-width:3px
    style Done stroke:#38ada9,stroke-width:4px

按顺序排列总是不是因为我懒惰

不是因为我不做价值测试

但是因为

这就是创造性工作是如何发生的

当你在探索问题空间时你还没有完全理解

不是因为我懒惰
不是因为我不做价值测试
但是因为
这就是创造性工作是如何发生的

当你在探索问题空间时你还没有完全理解

让我解释一下

第1阶段:使其发挥作用(私人书架)

这是乱七八糟的部分。我完全不知道自己在做什么

我在试着理解:

这个API真的和医生说的那样有效吗?

我能用我拥有的工具来解决这个问题吗?

在这种背景下,“正确”又意味着什么?*这是两个小时的问题还是两周的问题?*这是发明

这是探索。

这是爵士乐。

# Ugly, exploratory code
def process_thing(data):
    # TODO: This is terrible, fix later
    result = []
    for item in data:
        # Not sure if this is the right approach...
        x = item.get('value')
        if x:  # Is this even the right condition?
            result.append(x * 2)  # Why multiply by 2? Testing something...
    return result

你知道什么能杀死爵士乐吗?**有人站在你的肩膀上说"先写试卷"**为什么还没有测试呢?

因为形状是静态的流体想象你是一个雕塑家

你有一个大理石块和一个模糊的想法: "我想刻一只鸟。"

TDD说:“在你碰那颗大理石之前, 写下鸟的长相。

定义它的翼展。指定每根羽毛的角度。

现在按照这些规格来刻"*这不是... 不是鸟儿怎么被雕刻的。 (或者软件被写成,因为事实证明。 )*真正的雕塑家

先整理一下表情他们素描。

他们做玛格特它们耗尽了一大块石头以寻找一般形状只有在以后,它们才完善细节。

代码是相同的。

第一阶段,我写道:

这个代码是

私人的。

这是和我自己的谈话

所以我才知道"工作"到底意味着什么

写作测试比无用更糟糕,

积极有害。

因为每当我意识到"哦,等待,这整个方法是错误的," 我不得不改写测试。

这不是僵硬的。

那是官僚作风

" 快速失败的自由 " 组织

# Before (Phase 1) - Exploratory code
def process_thing(data):
    result = []
    for item in data:
        x = item.get('value')
        if x:
            result.append(x * 2)
    return result

# After (Phase 2) - Refined code
def extract_doubled_values(items: list[dict]) -> list[int]:
    """Extract 'value' field from items and double each one.

    Only includes items where 'value' is present and truthy.
    """
    return [
        item['value'] * 2
        for item in items
        if item.get('value')
    ]

第一阶段即将到来

// Before (Phase 1) - Exploratory code
public List<int> ProcessThing(List<Dictionary<string, object>> data)
{
    var result = new List<int>();
    foreach (var item in data)
    {
        if (item.ContainsKey("value"))
        {
            var x = item["value"];
            if (x != null)
            {
                result.Add(Convert.ToInt32(x) * 2);
            }
        }
    }
    return result;
}

// After (Phase 2) - Refined code
/// <summary>
/// Extracts 'value' field from items and doubles each one.
/// Only includes items where 'value' is present and non-null.
/// </summary>

public IEnumerable<int> ExtractDoubledValues(IEnumerable<IDictionary<string, object>> items)
{
    return items
        .Where(item => item.ContainsKey("value") && item["value"] != null)
        .Select(item => Convert.ToInt32(item["value"]) * 2);
}

学习速度。

一小时后我要尝试五种不同的方法

我得发现我想使用的第三方图书馆... 并不像广告上说的那么好我需要意识到我所要解决的问题并不是我所要解决的问题应:*正在解决。*测试放慢了速度。

并不是因为测试缓慢,而是因为

过早说明是死亡。
如果我在了解问题之前写测试书我在写测试书
错误的事情。

然后我在感情上投入了错误的东西。

然后我在代码审查中为错误的事情辩护

最好能快速失败, 私下, 没有测试来维持, 没有自我保护。*第一阶段“工作”意味着什么?*意思是:"我运行了它。

我给了它一些投入。

# Phase 1: Works, but awkward to use
process_thing(data)

# Phase 2: Clear, flexible, composable
extract_doubled_values(
    items,
    scale_factor=2.0,
    include_zeros=False
)

它产生的产出似乎是合理的。

// Phase 1: Works, but awkward to use
ProcessThing(data);

// Phase 2: Clear, flexible, composable
ExtractDoubledValues(
    items,
    scaleFactor: 2.0,
    includeZeros: false
);

// Or even better with a fluent API
items.ExtractValues()
     .Scale(by: 2.0)
     .ExcludingZeros()
     .ToList();

我60%有信心我现在明白问题所在了。”

就是这样。**没有边缘病例。**没有错误处理。

graph LR
    subgraph "Phase 2 Refinement Process"
        A[Rough Code] --> B[Clean Structure]
        B --> C[Add Types]
        C --> D[Polish API]
        D --> E[Static Analysis]
        E --> F{Quality Gates Pass?}
        F -->|No| G[Fix Issues]
        G --> B
        F -->|Yes| H[Ready for Phase 3]
    end

    style A stroke:#ff6b6b,stroke-width:3px
    style H stroke:#95e1d3,stroke-width:3px

没有优雅。

只是个钉子而已一个概念的证明。

一个草图。第2阶段:使它美化(改进)

好了现在我明白问题所在了我有一些东西可以工作, 至少是为了幸福的道路。

现在我可以开始关心质量了

第2阶段是第1阶段:
1. 目标 1. 目标
清理混乱

Python 示例:*C# 示例:*更好的名字。

说明类型。*XML 文档。*实施清洁的LINQ。

2. 目标

与标准对齐

现在我知道我在建什么了我回到原来的要求确定我正在解决

右右右右右

问题,不仅仅是

a a/问题。

这往往揭示出差距:

"哦,他们想要这个处理负数不同处理负数。"

**"等等,有一个边缘案例价值可能是无对0"**标本上写着"双倍" 但我想它们的意思是"根据一个可配置因素来标度"
**我修复这些。**有时我回过头来说:“事实上,我们应该做X,因为Y。”
3 个波兰 API 表面
我想到的就是这里来电者的

经验。**皮顿:**C# :

更好的命名。

明智的缺省。
配置配置。
酌情提供流利的API。
这是
飞行器。

这是好软件的源头

为什么还是不做测试?

def test_extract_doubled_values_basic():
    items = [{'value': 5}, {'value': 10}]
    assert extract_doubled_values(items) == [10, 20]

def test_extract_doubled_values_skips_missing_values():
    items = [{'value': 5}, {'name': 'foo'}, {'value': 3}]
    assert extract_doubled_values(items) == [10, 6]

def test_extract_doubled_values_handles_zeros():
    items = [{'value': 0}, {'value': 5}]
    # By default, zeros are excluded (falsy)
    assert extract_doubled_values(items) == [10]

def test_extract_doubled_values_includes_zeros_when_configured():
    items = [{'value': 0}, {'value': 5}]
    assert extract_doubled_values(items, include_zeros=True) == [0, 10]

def test_extract_doubled_values_custom_scale_factor():
    items = [{'value': 5}]
    assert extract_doubled_values(items, scale_factor=3.0) == [15.0]

def test_extract_doubled_values_rejects_negative_scale_factor():
    with pytest.raises(ValueError):
        extract_doubled_values([], scale_factor=-1.0)

def test_extract_doubled_values_handles_empty_list():
    assert extract_doubled_values([]) == []

def test_extract_doubled_values_handles_non_numeric_values():
    items = [{'value': 'not a number'}]
    with pytest.raises(TypeError):
        extract_doubled_values(items)

哦,我不断运行它。

我有一个REPL打开。

我在尝试不同的投入
我在练习所有的道路
但我没有
把这些实验写成正式的测试

为什么?

因为

# This comment will drift from reality:
# Doubles all numeric values, skipping None

# This test will fail if reality changes:
def test_extract_doubled_values_skips_none_values():
    items = [{'value': None}, {'value': 5}]
    assert extract_doubled_values(items) == [10]

我还在发现值得测试的东西

在第一阶段我不知道这个功能是否会存在在第二阶段,我发现:"哦,比例因素不能是负的。

这是一个验证。"

"如果清单是空的,我们应该返回空的,而不是空的。""我们需要优雅地处理非数字价值"

这些深刻见解

从重构中浮现出来。

它们不是显而易见的先锋。

如果我在第一阶段做笔试我现在就要改写如果我写了
之后我改进了实施程序第一次就会正确
**第3阶段:以测试锁定它(分享阶段)**好吧,现在它是真实的。

代码是干净的。*API是有道理的。*我调查过边缘的案子了

我对我所造的东西有信心

现在,我写测试。

很多的测试。

近乎全面覆盖的测试。为什么现在?

因为

测试是一种共享机制。已经不是给我的了

我已经非常了解这个代码了

我在里面生活了数小时或数天
测试用于:
未来我
三个月后,他将忘却一切事物。我的队友们(需要信任这个代码的人)

CI 输油管

(需要防止倒退)

未来维护者

(需要安全重构这个因素)

测试是演示演示文图层

支持我的执行工作。这些文件:

本代码的用法哪些输入有效期望产出

我考虑过的边缘情况

我做了什么假设

全面覆盖,无妥协

在第三阶段,我努力进行测试:
这是安全网
现在,我的队友们可以:

有信心修改此函数

了解边缘情况
即刻出现渔获回归
无恐惧的再反应

作为文档的测试

良好的测试比评论更好的文件记录:测试不说谎它们不能漂移。
如果行为改变,测试中断。
那是

可执行文档。

所以测试才有价值
共有边界*关键是:*第三阶段发生在其他人接触密码之前
我不分享代码没有测试。

从来没有。

graph TB
    subgraph "Traditional TDD (Red-Green-Refactor)"
        TDD1[Write Failing Test] --> TDD2[Write Minimal Code to Pass]
        TDD2 --> TDD3[Refactor]
        TDD3 --> TDD1
    end

    subgraph "Three-Phase Approach (Explore-Refine-Lock)"
        P1[Explore Solution Space] --> P2[Refine Implementation]
        P2 --> P3[Write Comprehensive Tests]
        P3 --> P4[Share With Team]
    end

    style TDD1 stroke:#ffaa00,stroke-width:2px
    style TDD2 stroke:#ffaa00,stroke-width:2px
    style TDD3 stroke:#ffaa00,stroke-width:2px
    style P1 stroke:#ff6b6b,stroke-width:3px
    style P2 stroke:#4ecdc4,stroke-width:3px
    style P3 stroke:#95e1d3,stroke-width:3px

但我也不会在代码准备共享之前写测试这些阶段是:

私人私人私人勘探(只有我,没有测试)

私人装修私人装修

(只有我,还是没有测试) |-----|-------------| 公共分享 (测试 CI 代码审查整个九码) 这保护我的创造力和 | 我的队友的理智。为何保护创意

TDD鼓吹者说"测试能让你有信心重构因素"

没错!但前提是你已经知道你在建什么了

当我进入第一阶段时我不需要信心来重构因素

Hour 1: Write test for API I haven't designed yet
Hour 2: Realize the API is wrong, rewrite test
Hour 3: Discover a better approach, rewrite both
Hour 4: Finally get it working
Hour 5: Rewrite tests to match what actually works

我需要许可才能把一切都扔掉

Hour 1: Explore 3 different APIs, settle on the best one
Hour 2: Refine the implementation, handle edge cases
Hour 3: Write comprehensive tests for what I built
Hour 4: All tests pass, commit with confidence

测试造成了心理债务。

一旦我写好了,我就不愿意删除了

即使他们测试错了通过将试验推迟到第三阶段,我保留第一阶段和第二阶段

心理上便宜。

我可以:

尝试野生想法
丢弃全部方法
彻底改变设计

发现我的问题实际解决

完全没有负罪感 "但我写了所有那些测试..."

这就是创造力的运作方式。

// Test 1: Write test first (but I don't know the right API yet)
[Test]
public void TestProcessData()
{
    var processor = new DataProcessor();
    var result = processor.Process(new[] { 1, 2, 3 });
    Assert.That(result, Is.EqualTo(new[] { 2, 4, 6 }));
}

// Implementation 1: Make it pass
public class DataProcessor
{
    public int[] Process(int[] data) => data.Select(x => x * 2).ToArray();
}

// Later: Realize I need configurability, rewrite test
[Test]
public void TestProcessDataWithFactor()
{
    var processor = new DataProcessor();
    var result = processor.Process(new[] { 1, 2, 3 }, factor: 3);
    Assert.That(result, Is.EqualTo(new[] { 3, 6, 9 }));
}

// Later: Realize I should use IEnumerable, rewrite test again
[Test]
public void TestProcessDataEnumerable()
{
    var processor = new DataProcessor();
    var data = GetLargeDataset(); // This should be lazy
    var result = processor.Process(data, factor: 3);
    Assert.That(result.Take(3), Is.EqualTo(new[] { 3, 6, 9 }));
}

你先草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草地草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草草

你不能从细节开始

// Phase 1: Explore (no tests yet)
public int[] ProcessThing(int[] data)
{
    return data.Select(x => x * 2).ToArray();
}
// Try it: var result = ProcessThing(new[] { 1, 2, 3 });
// Hmm, what about configurability? What about lazy evaluation?

// Phase 2: Refine (still no tests)
public static class DataProcessorExtensions
{
    public static IEnumerable<int> Scale(
        this IEnumerable<int> source,
        int factor = 2)
    {
        return source.Select(x => x * factor);
    }
}
// Try it: var result = data.Scale(factor: 3).ToList();
// Much better API!

// Phase 3: Lock it down (NOW write tests, correctly)
[TestFixture]
public class DataProcessorTests
{
    [Test]
    public void Scale_DefaultFactor_DoublesValues()
    {
        var result = new[] { 1, 2, 3 }.Scale();
        Assert.That(result, Is.EqualTo(new[] { 2, 4, 6 }));
    }

    [Test]
    public void Scale_CustomFactor_ScalesCorrectly()
    {
        var result = new[] { 1, 2, 3 }.Scale(factor: 3);
        Assert.That(result, Is.EqualTo(new[] { 3, 6, 9 }));
    }

    [Test]
    public void Scale_LazyEvaluation_DoesNotEnumerateImmediately()
    {
        var enumerated = false;
        var data = GetTestData(() => enumerated = true);
        var scaled = data.Scale(factor: 2);

        Assert.That(enumerated, Is.False, "Should not enumerate yet");

        scaled.ToList();
        Assert.That(enumerated, Is.True, "Should enumerate on materialization");
    }

    [Test]
    public void Scale_EmptySequence_ReturnsEmpty()
    {
        var result = Enumerable.Empty<int>().Scale();
        Assert.That(result, Is.Empty);
    }
}

如何与 Agile 和 XP 相匹配( 以及它在哪里被冲移)

让我们说清楚一点:

这不是"考验后期发展"

这是

"在开发时进行试验,但时机合适"时间时间时间时间时间时间时间时间时间时间时间时间时间时间时间时间时间时间时间时间 :
何时

添加单位测试是关键。

太早了,你正在说明未知。
太迟了,你没有安全网的运输。

保存 XP 惯例

极端方案制定有值得遵循的杰出做法:
连续整合

每个功能在合并前都通过 CI

自动测试运行于向主没有破碎的建筑被容忍配对方案/守则审查
第三阶段代码在共享前接受审查

测试是可审查的艺术品的一部分

协作改进改进设计简单设计

第2阶段

全部约
简化简化
删除您不需要的东西
尽可能简单,不要简单

重构

第2阶段是专用重构时间清除代码之前

锁定它

**测试保护再构件(第3+阶段)**在那里我从严格TDD下潜

TDD说:"首先测试。

总是红绿因子是唯一的方法。”

**我说:**当你知道你在测试什么时就会进行测试

探索 -Refine -Lock更自然。"

关键区别 :

TDD 三阶段测试定义界面勘探定义界面

探险 -Refine -Lock进展
实施前的测试完成前的测试完成前的测试完成前的测试完成前的测试完成前的测试完成前的测试完成前的测试完成前的测试完成前的测试完成前的测试完成前的测试完成前的测试完成前的测试完成前的测试完成前的测试
共享共享共享

对每件事情首先进行测试每件事情在正确的时间进行测试

微周期(分钟) 宏观阶段(小时/天)
时机是关键
关键的观点是:
这不是"最后的测试",而是"分享前的测试"
错误的时间( 太早) :

正确时间( 第3阶段) :

质量结果相同。一半的胡萝卜这是 IS 缩放

Agile说:

"响应改变而不是按照计划。"贸发司可成为其自己的计划执行形式。

一旦你写了测试书你就会在心理上投入到设计中

我的方法包括改变:
第一阶段:迅速变化,找到正确的解决办法
第2阶段:有意改变,逐步走向优雅
第3阶段:认真修改,保护有效的东西

这是更多

比严格的TDD敏捷, 因为它推迟承诺直到你得到信息。

对比方法:A C# 示例

严格TDD方法:

注意了吗?

随着设计的发展,三次测试重写。

**三阶段办法:**一套测试
写过一次第一次纠正
因为我知道我在建什么Agile 宣言连接

记住值 :

“综合文件工作软件”

第一阶段获得工作软件

快速快速

第3阶段测试综合文件"响应计划后的变化"
1-2阶段包括变化第3阶段最后设计中的锁
**“过程和工具的内在和相互作用”**不要让TDD教条压倒好判断

当合作有帮助(第2-3阶段)时,合作协作(第2-3阶段),不合作时,单独探索(第1阶段)

"在合同谈判方面进行海关合作"

第二阶段与规格一致

之后

了解问题更好地交付他们需要的东西,而不是他们具体指明的东西
为何会减少无用之春TDD的肮脏秘密:
**实施前写的大多数测试都经过重写或删除。**为什么?

因为:

你误会了要求

你还不知道那些边缘的案子呢你发现了更好的API设计你意识到这个功能根本不需要

你写在第一阶段的每个测试都可能是浪费了精力

写得更好

1个

第3阶段的一组测试, 当你实际知道自己正在建造什么, 而不是在勘探期间写- 重写- 重写- 重写。TDD承诺与现实TDD承诺:

"Write code that solves the specification.
Don't worry about perfection yet.
Just get it working."

"测试驱动你的设计!

他们帮助你发现好的API!"
TDD 现实:
"我写了一本API的测试书" "我认为这很合理"
然后,我实施了它, 并意识到API是尴尬的。

现在我正在重写测试和代码。”**这不是设计。**那是

哀号!我的方法:

通过实施设计,然后通过测试将其锁定。

最后的结果是相同的、经过良好测试的、设计完善的代码。
但我得到了那里与一半的胡萝卜。
为什么这个仍然提供有纪律的软件
这个方法是这样的
否:
"牛仔编码"

"没有测试"*(欢呼和祈祷)*当我完成第三阶段的时候我的代码有:

全面测试覆盖率处理的边缘案件

清洁、可读实施

清除 API 设计文件(通过测试)

和TDD完全一样

区别在于
- 何时
- 这些测试是书面的。
- 纪律来自边界

规则很简单:

- flake8 (style checking)
- pylint (code quality)
- mypy (type checking)
- black (formatting)
- radon (complexity analysis)

**代码不能留下第2阶段没有第3阶段的代码。**我不认为:

for iteration in range(3):
    # Measure current performance
    metrics = measure_performance(code)

    # Generate improved version
    better_code = optimise(code, metrics)

    # Keep if better, discard if worse
    if better_code.score > code.score:
        code = better_code

未测试的代码不加测试的开放的PRP合并到主控面而不经过 CI

无覆盖面报告部署部署
纪律不是早期写作测试
进去了
没有测试就无法共享代码。
手工艺符号

这不是个新想法这就是创造性的工作总是有效的:

折叠

画家不会从最后的刷孔开始*它们:*书样组成(第1阶段)

绘画画画画画*两层(第2阶段)*配色

# Test generation happens AFTER optimisation
def generate_unit_tests(specification, optimized_code):
    """Generate comprehensive tests for refined code.

    This happens in Phase 3, after we know:
    - What the code actually does
    - What edge cases exist
    - What the API surface looks like
    """
    return llm.generate(
        f"""Generate comprehensive unit tests for this code.

Specification: {specification}
Implementation: {optimized_code}

Include tests for:
- Happy path (from spec examples)
- Edge cases (discovered during optimisation)
- Error conditions (based on actual error handling)
- Performance bounds (based on measured metrics)
"""
    )

保护和现(第3阶段)

清漆不是第一位的
但它不是可选择的。
编辑出版
作家们不会像他们一样编辑

它们:草案草案草案草案草案草案(第1阶段)

编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑编辑**无情(第2阶段)**出版出版
有自信(第3阶段)**"写醉,编辑清醒" 是可怕的生活建议但伟大的写作建议。**Clay 灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色灰色
波特在塑造之前不会闪闪发光**它们:**丢弃
粘土(第1阶段)修整和精细窗体(第2阶段)冰川和火灾

**耐久(第3阶段)**玻璃是关键。

但它是最后的。

此图如何映射到 DISE 代码元管道有趣的是,我实际上已执行已执行

这是DISE(分散的合成进化)系统中的哲学。

编码管道明确体现了这三个阶段:
第SE阶段1:勘探阶段
当您要求 DISE 解决问题时, 它不会直接跳到写出完美的, 测试过的代码。
相反,

发电机发电机

(代码或类似的)获得明确授权:
该系统生成探索代码 :
关注幸福的道路
最小错误处理

不过早优化

仅足以测试这一方法然后执行器
运行它。*不进行正式的单位测试——只是根据规格中的投入。*如果失败了?
没问题那是学习。
该系统有6个阶段的适应升级:

尝试快速模型( 低温)

以更高的创造性( 高温) 再试一次

User: "Calculate fibonacci numbers"

[Phase 1: Exploration - 3 attempts]
  Attempt 1: Works for small inputs, explodes on large ones (no safety limit)
  Attempt 2: Adds safety limit, but inefficient recursive approach
  Attempt 3: Switches to iterative DP (PASS)

[Phase 2: Optimization - 3 iterations]
  Iteration 1: Add type hints, improve naming (Score: 1.05)
  Iteration 2: Optimize memory usage with generator (Score: 1.10)
  Iteration 3: Add input validation (Score: 1.15)

[Phase 3: Testing and Storage]
  Generated 8 unit tests covering:
    - Basic cases (n=0, n=1, n=5, n=10)
    - Edge cases (n=negative, n=100, n=None)
    - Type validation

  All tests pass ✓

  Stored in RAG with quality score: 1.15
  Available for reuse: YES

升格为更强大的模型

添加调试记录来理解失败
赋予强势模式以充分背景
将“上帝一级”模式作为最后手段使用
这是

精确1. 第一阶段。

该系统正在探索解决方案空间,学习什么是有效的,什么是迅速失灵和适应。

在这一阶段没有写任何测试。代码是生成过程的私密代码。

DISE第2阶段:优化阶段一旦代码通过基本执行程序,DISE就移动到最优化。

**这是完善阶段。**系统:
清理执行过程删除失败时添加的调试记录
简化过于复杂的代码改进命名和结构
运行静态分析顺势选择性

(3个默认迭代)

这是精确

2. 第二阶段。

代码仍然是私有的(尚未在登记册中), 但我们正在擦拭它:更好的名称

类型提示类型洁净结构

低复杂程度

改善业绩形状不再是液态了

我们知道我们正在建设什么。

瞷и瞷暗不错。
第SE阶段第3阶段:试验和储存阶段仅
之后优化 DISE 生成并运行

正规单位测试。

关键部分是: 测试来自
完善的规格规定和执行
,而不是最初的勘探。

测试内容包括:*具体实例(正确性)*第二阶段期间发现的边缘病例

改进过程中添加的错误处理

测量的性能特征*然后,*仅在测试通过

代码是:

存储于

RAG 内存

# I know what sort() should do. Tests first? Sure!
def test_sort_empty_list():
    assert sort([]) == []

def test_sort_single_element():
    assert sort([5]) == [5]

def test_sort_multiple_elements():
    assert sort([3, 1, 2]) == [1, 2, 3]

(有嵌入)

添加到节点登记册:

(作为可执行的文物)
可供用于
再利用

未来工作流程

与

质量分数