企业官网建设流程全解析

1. 这个项目起于一个偷懒念头

去年下半年，我大部分时间都在和业务代码打交道，写来写去无非是接口对接、数据清洗、CRUD。说实话，这类代码写多了以后你会发现，真正让人头疼的不是某个算法难题，而是大量的“套路化”劳动——拿到需求文档，翻译成代码，调试，修格式，再修边界。干久了很容易怀疑人生。

当时我也在用一些AI编程助手，确实能帮上不少忙，但总觉得差点意思。它们在IDE里像个聪明的补全工具，会接上下文，但你要让它“根据一句话描述直接生成整个函数”，往往得来回调好几次提示词，生成完还得自己搭架子、处理依赖、确认编译。沟通过程充满了“你懂我意思了吧？”这种不太确定的默契感。

后来我突发奇想：与其每次都在编辑器里跟AI工具互相试探，不如自己搭一个轻量服务，把“自然语言转代码”这件事做成一条流水线。我给它起了个名字叫t3code，T3念快了就是“text”的音，含义很直接——text to code，把文本描述变成可运行的代码。这个小项目后来发展成了一个包含意图识别、代码生成、静态检查、动态验证四个环节的个人工具，这篇文章就是把它从零到一实现的全过程记录。

如果你也经常被“写重复代码”折磨，或者你想搞明白AI写代码这事在大模型之外还需要补哪些工程环节，这篇文章应该能给你一点不一样的思路。我会把架构设计的理由、每段关键代码、以及实际跑出来的翻车案例都摊开讲，不藏着掖着。

2. 为什么不直接用现成AI工具：我的取舍与分析

动手之前，我先把市面上能用的方案捋了一遍。大部分AI编程助手都走“IDE插件”路线，主打的是补全、问答和代码解释。它们很擅长“你正在写函数A，我帮你把函数A写完”，但其实不太擅长“你只给我一句话，我给你交付一个能跑的模块”。本质上是因为交互模式决定了它们必须把注意力放在“局部上下文”上，而不是“从一个意图出发，逐步展开成完整产物”。

我还试过一些在线代码生成平台，它们能做到“输入描述，生成代码”的Demo效果，但问题在于它们生成的代码往往是一坨“看起来很美”的孤立文件。没有入口函数、没有依赖说明、没做语法检查，你拿到手里还要花时间做二次加工。这就像买家具送了你一堆木板，却不给你螺丝和图纸，最终还是要自己动手。

所以我对t3code提出了三个明确的设计目标：

1. 输入要口语化。哪怕用户描述得不够规范，比如“任务列表接口，支持分页和按标题模糊搜”，系统也得能兜住。
2. 产出要“闭环”。不只是生成代码片段，而是生成一个能编译、能跑通最小测试的东西。
3. 拆解要透明。代码生成这种黑盒操作，中间每个环节都得能追溯，出了问题我知道是哪一步带歪了。

这三个目标其实已经决定了我不能只写一个“大模型API调用封装”，而是要围绕大模型搭一套带工程约束的流程。

在技术选型上，我最终决定：Python + FastAPI做服务壳子，LangChain做上下文编排，OpenAI兼容的Chat模型做生成内核，pylint / mypy做静态检查，pytest + 反编译执行做动态验证。这套组合不是最炫的，但足够稳，而且每个组件都独立，未来换模型、换检查器都方便。

不过这里我要说一句公道话：选型只是开始，真正的难点从来都是流程设计。大模型写代码已经是成熟能力，难的是你怎么让它稳定地产出质量可接受的代码，并在出错时能自动兜回来。下一节我就把这条流水线的四段结构摊开讲。

3. 流水线四段式架构：意图解析、代码生成、静态检查、动态验证

t3code 的完整处理链路是这样设计的：

用户输入（自然语言描述） -> 1. 意图解析：结构化抽取需求要点 -> 2. 代码生成：基于结构化描述生成完整模块 -> 3. 静态检查：语法、类型、规范问题无效则打回 -> 4. 动态验证：编译执行 + 跑最小测试 -> 返回结果（代码 + 验证报告）

这个顺序是有讲究的。如果一开始就拿原始口语输入让大模型写代码，容易丢信息、产出跑偏；如果跳过静态检查直接去跑动态验证，又会浪费大量时间在低级语法错误上，而且报错信息会淹没真正重要的逻辑问题。

3.1 第一段：把口语“翻译”成结构化描述

我们假设用户输入是这么一句话：

写一个Python函数，输入是字符串列表，过滤掉长度小于3的项，然后按字母排序返回

这段描述人类能看懂，但要让大模型稳定产出好代码，最好先把它解析成结构化的JSON。这一步我用了一个自定义的解析Prompt，让模型输出几个固定字段：任务类型、输入输出、核心逻辑、依赖库、约束条件。

实际Prompt长这样（简化版）：

你是一个需求分析器。把用户的编程需求解析为JSON，包含以下字段： - task_type: 任务类型（function/class/api/script） - inputs: 输入描述列表，每项包含name和description - outputs: 输出描述 - logic: 核心逻辑步骤列表 - dependencies: 需要的第三方库列表 - constraints: 其他约束条件 用户说：{user_input} 只输出JSON，不要解释。

这一步的价值是巨大的。它把“请帮我写个程序”这种模糊的请求，变成了生成阶段能够稳定消费的中间产物。我试过跳过这步直接让大模型生成代码，结果同样的输入在不同轮次会出来风格完全不同、甚至理解偏差很大的代码。加上意图解析层之后，输出稳定性明显提升了。

这就像你请人帮忙做饭，如果你只说“随便做点吃的”，可能出来一锅乱炖；但如果你说“两个人吃，半小时内能做好，不要辣，有主食有肉”，对方就有了明确的执行边界。

3.2 第二段：让大模型基于结构化需求生成“可落地”的代码

拿到结构化JSON后，下一步是组装代码生成Prompt。这一步的关键不是“让模型写代码”——模型本来就会写——而是如何把工程约束嵌进提示词里。我在Prompt里固定了几个硬性要求：

• 必须包含函数/类的完整定义和类型标注
• 必须包含入口示例（if __name__ == "__main__"或者测试用例）
• 必须处理明显的边界条件（空输入、异常类型等）
• 禁止使用不确定的占位符，比如TODO、pass
• 依赖库必须在dependencies字段中声明，并在生成代码头部import

代码生成Prompt的核心段落如下：

基于以下结构化需求生成Python代码： {structured_requirement_json} 要求： 1. 代码必须完整可运行，不能有TODO/占位符 2. 所有函数必须有完整类型标注 3. 必须包含一个演示用入口（if __name__ == "__main__"） 4. 第三库依赖必须显式import 5. 代码风格遵循PEP8 6. 输出格式：**CODE_START**开头，**CODE_END**结尾

为什么要求“完整可运行”而不是“代码片段”？因为我后来发现，大模型在生成孤立函数片段时质量很高，但一旦要求它写出“带入口、带类型标注、带边界处理”的完整模块，它的注意力会被拉高，产出的代码反而更稳。这是一种反直觉但实测有效的Prompt技巧。

另外，用**CODE_START**和**CODE_END**包裹代码输出，是为了后面解析方便——大模型的回复里往往夹杂说明文字，没有这种明确的边界标记，截取代码时会非常痛苦。

3.3 第三段：静态检查必须前置，原因没有你想的那么复杂

代码生成之后，我没有急着执行，而是先跑静态检查。这一步有两个工具配合：pylint负责代码规范和可疑写法，mypy负责类型标注是否自洽。

静态检查的作用不只是“找毛病”，更大价值是给生成环节提供纠错信号。如果静态检查不过，我生成环节会拿到具体的错误列表，然后让大模型基于这些错误信息做一轮“修复生成”。这个循环我会让它最多跑三次，三次还过不了就直接返回失败，避免无限折腾。

这里有一个很实际的教训：如果是语法错误，大模型看到报错信息后基本一刀就能修好；但如果是逻辑层面的问题，比如整个设计方向就错了，让大模型反复修十次可能也修不对。所以判断错误类型，决定要不要进入修复循环，是整个流程里非常关键的人为决策点。

3.4 第四段：动态验证，伪代码杀手锏

静态检查通过，不代表代码真的能跑。最后一步是动态验证。我在一个受限的执行环境中运行生成的代码，并跑几个简单断言。如果代码有内置的入口示例，就直接执行入口函数；如果生成的是函数，就构造几个典型输入做测试。

我动态验证的最小测试是从生成代码里自动提取的，而不是预设的cases。提取方法是：在代码生成的Prompt里就要求模型同时产出一组断言样例。也就是说，大模型在写代码时，也顺带帮我把单测写了。这两个功能在同一个Prompt里完成，既不增加请求次数，又能保证测试和代码逻辑的连贯性。

# 动态验证的核心逻辑（简化版） import subprocess import sys def run_validation(code_str: str, test_cases: list[dict]) -> list[dict]: results = [] for i, case in enumerate(test_cases, 1): test_code = f""" {code_str} result = {case['call']} assert abs(result - {case['expected']}) < 1e-6, f"expected {case['expected']}, got {{result}}" """ try: exec(test_code) results.append({"case": i, "status": "pass"}) except Exception as e: results.append({"case": i, "status": "fail", "error": str(e)}) return results

这块执行环境我是加了限制的：超时控制、禁用网络访问、限制内存。毕竟跑的是大模型写的代码，再怎么说也不能让它把宿主机器搞崩了。用Python的resource模块限制子进程CPU时间和内存上限，是一个既轻量又有效的沙箱思路。真要搞什么容器隔离、gVisor，那是大型平台该干的事，个人项目没必要开那么重的枪。

4. 动手实现：核心模块与关键代码解剖

整体架构讲完了，这一节直接上实现。t3code的代码我拆成了几个模块，每个模块干一件事，方便单独测试和替换。但我不会把全部代码贴出来——那太长了，而且大部分是机械代码。我只挑几个关键实现段，讲清楚它们为什么这么写。

4.1 服务入口：FastAPI壳子

服务用FastAPI搭，核心就是提供一个/generate接口，接收用户描述，返回生成结果。FastAPI的好处在于自带请求校验和接口文档，调试时直接在浏览器里看Swagger UI，省事到不行。

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI(title="t3code") class GenerateRequest(BaseModel): description: str language: str = "python" auto_fix: bool = True class GenerateResponse(BaseModel): code: str verification_report: list used_fix_rounds: int @app.post("/generate", response_model=GenerateResponse) async def generate(req: GenerateRequest): return await pipeline.run(req)

这里我用了pydantic的BaseModel，好处是接口的入参、出参都强类型化，后面接前端、接CLI都很方便。整个服务无状态，可以横向扩展，不过个人用其实一个进程就够了。

4.2 意图解析模块：结构化是稳定性的基石

这是t3code里我最满意的一部分。它的核心价值我之前提过——把模糊口语变成结构JSON，让下一环节输入干净可控。

实现上我没有直接用LangChain的create_extraction_chain，而是手写了Prompt +JSONOutputParser。原因是LangChain的抽象在这一块绑定比较死，出了问题反而更难排查，我的业务逻辑其实很简单，直接用原生写法更透明。

from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import JsonOutputParser from langchain_openai import ChatOpenAI llm = ChatOpenAI(model="gpt-4o", temperature=0) parser = JsonOutputParser() prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个需求分析器，把用户的编程需求解析为JSON，包含task_type、inputs、outputs、logic、dependencies、constraints字段。只输出JSON，不要解释。"), ("human", "{user_input}") ]) chain = prompt | llm | parser structured_req = chain.invoke({"user_input": "写一个Python函数，输入字符串列表，过滤长度小于3的项，按字母排序返回"})

注意这里我把temperature设成了0。做生成任务时，尤其中间还有解析依赖的任务，温度越低越稳定。JsonOutputParser会强制大模型输出合法JSON，否则会抛错重试，这就把“模型不好好输出”的问题挡在了早期。

4.3 代码生成模块：完整产出 + 自动备注

代码生成这步，我做了两个玩味十足的设计。第一，要求模型把关键决策写进注释；第二，要求它同时产出测试用例。这两点让后续的维护和验证都顺滑很多。

generate_prompt = ChatPromptTemplate.from_messages([ ("system", """ 你是一名Python高级工程师。基于结构化需求编写完整可运行的代码。 硬性要求： 1. 代码不可包含TODO、placeholder 2. 每个函数必须有完整类型标注 3. 必须包含 if __name__ == "__main__" 演示入口 4. 代码必须包含详细中文注释，解释关键逻辑 5. 必须包含一个test_cases列表，格式为[{"call": "function_name(...)", "expected": ...}] 6. 输出格式： **CODE_START** <代码> **CODE_END** **TESTS_START** <test_cases的JSON> **TESTS_END** """), ("human", "结构化需求：{structured_req}") ]) raw_output = generate_chain.invoke({"structured_req": json.dumps(structured_req, ensure_ascii=False)}) code, tests = parse_output(raw_output)

我让大模型把test_cases和代码一起吐出来，而不是单独生成，是因为这样测试和代码从一开始就在同一个上下文里，逻辑天然对齐。要是分开生成，测试样例可能和函数签名不一致，验证的时候就会自己打自己脸。

4.4 静态检查：把错误信息变成修复指令

静态检查这块不是简单的“报错就行”，我给它加了一层“错误翻译”的包装。pylint和mypy的原始输出是给人看的，但大模型需要的是精炼的修复指令。所以我解析了它们的输出，格式化成一串字符串，然后作为额外上下文给到修复Prompt。

# 将pylint/mypy输出压缩为修复指令 def format_check_errors(pylint_output: str, mypy_output: str) -> str: errors = [] for line in pylint_output.splitlines(): if "E:" in line or "F:" in line: errors.append(f"[pylint] {line.strip()}") for line in mypy_output.splitlines(): if "error:" in line: errors.append(f"[mypy] {line.strip()}") return "\n".join(errors) if errors else ""

为什么要做这层翻译？因为pylint的原始输出有时候信息太碎，一行一个warning，大模型容易抓到次要问题却忽略真正的error。我只保留E:和F:（错误、致命错误）级别的输出，warnings先不管。因为在这个场景下，warnings不影响运行，但error会，我们要优先解决“跑不起来”的问题。

4.5 修复循环：让错误信息有吃掉的意义

修复循环是这个项目的灵魂所在。大模型第一次生成的代码大概率不能一次通过，你不要灰心，更不要把锅全甩给模型——因为即使人类写代码也是改几轮才过编译的。

流程很简单：

第1轮：生成代码 -> 静态检查 -> 如有error -> 带error信息回到生成环节 -> 第2轮 第2轮：重写代码 -> 再检查 -> 如还有error -> 再到第3轮 第3轮：最后机会 -> 检查还不过 -> 整体失败

修复Prompt的关键是：给大模型看原始需求和错误信息的组合。注意，不要只给错误信息而不给原始需求，否则大模型会在没有任何背景的情况下瞎猜，越修越乱。我在Prompt模板里把两者都放进去：

fix_prompt = ChatPromptTemplate.from_messages([ ("system", "你是代码修复专家。基于原始需求和错误信息，重写完整代码。不要解释，直接输出代码。"), ("human", """ 原始需求：{structured_req} 生成代码的错误信息如下： {error_messages} 请重写完整代码，格式遵循之前的约定。 """) ])

这个循环我最多跑三次，跑完还不干净就放弃。因为从统计学上看，如果是单纯语法/类型错误，两轮内必好；如果三轮都还有问题，那多半是需求理解和代码结构的架构级问题，单靠“改错”修不回来，不如直接报失败让用户重新描述需求。给流程设置止损点，是工程判断，不是半途而废。

5. 实测记录：四个经典案例，有惊喜也有翻车

理论聊完了，来看实战。我拿t3code跑了大概一百多个需求，挑四个最有代表性的案例出来分析。

5.1 案例一：简单函数生成，一把过

输入：“写一个Python函数，输入字符串列表，过滤掉长度小于3的项，然后按字母排序返回。”

输出结果很干净，完整函数、类型标注、入口演示都有，test_cases也自动生成了。静态检查pylint给了一个consider-using-enumerate的轻微warning，但因为没有error级别，直接被放行。动态验证里三个断言全部通过。

from typing import List def filter_and_sort(items: List[str]) -> List[str]: """过滤长度小于3的字符串并按字母排序。""" filtered = [item for item in items if len(item) >= 3] return sorted(filtered) if __name__ == "__main__": sample = ["hi", "apple", "ok", "banana", "go", "cat"] print(filter_and_sort(sample)) test_cases = [ {"call": "filter_and_sort(['hi', 'apple', 'ok', 'banana', 'go', 'cat'])", "expected": ["apple", "banana", "cat"]}, {"call": "filter_and_sort([])", "expected": []}, ]

这个例子说明，对于描述清晰、逻辑简单的任务，现役大模型早就没有难度了，t3code要做的是稳定地把这条路走通。

5.2 案例二：包含第三方库，依赖标注的价值显现

输入：“用requests库抓取一个网页的标题，URL作为参数传入。”

这里有意思的是，如果不约束“必须声明依赖”，模型确实会写代码但没有import requests，或者在Docker里跑就炸。由于我在Prompt里强制了dependencies字段，意图解析阶段就识别出了依赖，代码生成阶段会自动补上import。整个流程一次通过，静态检查干净。

这算是t3code和纯大模型问答式写代码的显著区别：它能用自己的依赖声明机制把生成结果转成环境可运行的状态。虽然这在工程上是个很简单的约束，但对个人用户来说体验提升非常大。

5.3 案例三：两个奇怪的翻车，修复了三轮也没救回来

这个案例值得分享。输入是：“写一个函数，接收一个日期字符串（YYYY-MM-DD），返回它是一年中的第几天。”

直觉上这很简单吧？但前两轮生成的代码在闰年处理上都有bug，我设置的test_cases里包含了一个闰年2月29日的用例。第一轮代码用了datetime.strptime(date_str, "%Y-%m-%d").timetuple().tm_yday，逻辑没问题但跑出来闰年是对的，静态检查却报了一个not-callable的type检查问题——原因是模型在某些分支里把一个叫datetime的参数给覆盖了。

第二轮修复时，大模型看到了错误信息“datetime被覆盖”后，加了个from datetime import datetime as _dt变量改名，但新代码又把strptime写成了strtime，直接语法错误。

第三轮，它总算修对了语法。但此时我设置的动态验证引入了“日期输入不合法时抛异常”的隐藏断言，模型生成的代码抛的异常类型和预期不一致，依旧失败。三轮已过，直接放弃返回失败。

这个案例给我的教训有二。第一，大模型在“变量名遮蔽”这类作用域问题上经常踩同类型的坑，因为它在训练语料里见过的代码大多是简单写法，很少刻意避免这种隐患。第二，动态验证的断言语义越强，修复循环的成功率越低，因为每一轮修复相当于在重新解一道全新的题，并不会真的“吃一堑长一智”。

5.4 案例四：复杂业务描述，拆解能力的上限

输入是：“做一个库存管理系统CLI，支持添加商品、扣减库存、查看低库存警告，数据持久化到JSON文件。”

这个需求门类更大，模型生成的代码甚至有500多行，分了四个类，文件读写逻辑也有。但静态检查phase就挂了——pylint报了一堆too-many-instance-attributes和duplicate-code，最重要的是mypy报了一个"Inventory" is not defined的TypeError。

第一轮修复解决了“类引用顺序”问题；第二轮跑通了静态检查；但动态验证显示CLI输入循环无法正常退出，因为我设置的演示入口用了while True，没人给它发送EOF时它会一直挂着——这其实是测试设计的问题，不是代码真bug。验证器和被验证代码之间的协议不匹配，有时候比代码本身的bug更让人头疼。

案例四给我最大的启发是：t3code这类工具的核心矛盾不是“AI写不好代码”，而是“验证系统如何公平地评价代码”。如果验证协议设计得不好，我们很可能误杀本来写得不错的代码。

6. 实质优化：prompt迭代、自建模板库与检索增强

基础版跑通之后，我又做了一批优化。这些优化不是锦上添花，而是让这个工具从“偶尔好用”变成“经常好用”的关键。

6.1 Prompt模板库：与其让模型猜，不如给它看例子

我发现，对于同一类任务，比如“写一个CRUD接口”“写一个爬虫脚本”，模型其实完全知道该怎么做，但它不知道“你心中的CRUD是哪种风格”。于是我从使用记录里挑出靠谱的生成样例，做成了few-shot示例库。

做法是给生成Prompt加了可选字段：_few_shot_examples。从历史上找相同task_type的代码作为示例，塞进Prompt的system消息里，再让模型参考风格生成新代码。这相当于给模型一个标准答案参考，而不是让它凭空想象“这个用户的审美是什么”。

examples = example_store.find_by_task_type(structured_req["task_type"], top_k=2) if examples: few_shot_text = "\n".join(f"示例{i+1}:\n{ex['code']}" for i, ex in enumerate(examples)) else: few_shot_text = ""

这个改动带来肉眼可见的提升：生成代码的风格一致性提高了非常多。之前每轮代码长得像不同的人写的，现在至少同一个task_type下，缩进习惯、注释密度、命名风格基本统一，维护起来舒服多了。

6.2 从“修错误”到“验证逻辑”：抽象语法树检查

动态验证阶段之前直接用exec，有安全风险，而且不够灵活。后来我加入了AST检查作为“预检”步骤——先解析生成代码的抽象语法树，检查有没有危险调用（eval、subprocess、socket等），再决定要不要放行到执行阶段。

import ast blocked_keywords = ["eval", "exec", "subprocess", "os.system", "socket"] def ast_safety_check(code: str) -> list[str]: tree = ast.parse(code) issues = [] for node in ast.walk(tree): if isinstance(node, ast.Call) and isinstance(node.func, ast.Name): if node.func.id in blocked_keywords: issues.append(f"blocked call: {node.func.id}") return issues

这个检查简单粗暴，但很有效。它不解决“代码有没有bug”，只解决“代码是否会搞事”。对个人项目来说，这是一道非常有必要的闸门。如果你以后准备把这个工具开放给别人用，这一步绝对不能省略。

6.3 RAG增强：让它学会你项目的代码风格

最后一个比较大的优化，是给系统接了一个极简的RAG能力。我的场景是：团队内部项目常常有既有的代码风格和函数库，我希望t3code生成的代码能“人模人样”地融入现有项目，而不是一股大模型味。

做法很朴素：把团队代码库的零散文件灌进一个向量数据库，在代码生成时，按相似度检索出与当前任务相关的函数签名和调用惯例，作为生成Prompt的额外参考上下文。

# 用sentence-transformers做向量化示例（伪代码） from chromadb import Client from sentence_transformers import SentenceTransformer model = SentenceTransformer("BAAI/bge-small-zh-v1.5") client = Client() collection = client.get_or_create_collection("code_patterns") collection.add( ids=[str(i) for i in range(len(snippets))], documents=snippets, embeddings=[model.encode(s) for s in snippets], )

检索出来的参考片段会和结构化需求一起进入代码生成Prompt。实测效果非常好——尤其在生成“对接现有service层”这类代码时，模型会倾向于模仿参考代码里的函数命名和错误处理方式。这是从“让AI生成能跑的代码”到“让AI生成像你写的代码”的关键一步。

6.4 生成结果评分：别等到翻车才后悔

我最后加了一个轻量评分机制：每次生成代码后，根据静态检查通过率、动态验证通过率、AST安全检查结果、代码行数、注释覆盖率，给这次生成打个分。分数高就存进模板库，分数低就直接丢到日志里。

这个机制的价值不在于当下的提醒，而在于积累。时间久了，模板库越来越贴合自己的需求，整个系统的成功率会跟着上涨。你要是做个人工具，这绝对是性价比最高的一项投资，因为它不需要改任何算法，只是在收集数据。

7. 跑测期间的踩坑清单：每一条都是真金白银换来的

这部分我原本不打算写，因为有点丢人。但想想各位读者要是也在折腾类似的东西，这些坑能帮你们省不少时间，我还是展开聊聊。

7.1 长度陷阱：长代码直出时容易截断或静默丢尾

代码稍长一点的模块，大模型有时会在4000-6000 token附近悄悄截断，产生“代码写到一半就戛然而止”的问题，而且没有明确报错。静态检查一跑就是SyntaxError: unexpected EOF while parsing，修复循环跑第一轮就会遇到这种“残缺代码”。

我的应对方案有两个：第一，改用了支持更大输出上下文的模型版本；第二，把解析层做了保护——如果**CODE_END**标记缺失，就判定生成失败，并随机截断后半部分重发一次。这种“感知到截断就重启”的策略，比让fix循环硬着头皮去修残缺代码有效得多。

7.2 上下文膨胀：把历史错误越修越多

我在修复循环里最初的设计是：修复代码时把完整错误信息给模型看。结果第二个案例里，第一轮的pylint报了一大串问题，模型全部读进去，修A的时候把原来没问题的B也顺手改了，结果引入新错误。越修越乱，最后直接失控。

现在我做的改进是：修复时的错误信息只给error级别的关键信息，warnings一律过滤。同时让模型在修复前先明确“不要改那些没报错的部分”，这个显式的行动约束能让它在修改时收敛很多。

7.3 沙箱不是可选项：第一次跑动态验证就翻车

我最初为了省事，动态验证直接在主进程里exec。结果有一次生成代码里有个死循环，卡了半分钟，进程才被系统杀掉——而且它卡掉前已经把系统资源吃满了。从那以后我学乖了，强制所有执行环节走子进程+超时控制。没这个隔离，个人电脑分分钟被AI生成的“坏代码”拖垮。

如果你在自己电脑上跑类似项目，我给的建议就一句话：默认执行环境就是子进程，绝不信任生成代码。

7.4 中文描述容易带偏生成结构

我们平时用中文描述需求，但中文偏向“意合”，很多边界条件和异常处理是不言自明的。比如“输入是字符串列表”这句话，中文使用者默认“如果不是字符串类型会怎样”大概率不关心，但大模型生成代码时会犹豫要不要处理类型异常。

我的做法是在意图解析阶段强制模型把约束字段补全：是否允许空输入、是否需要类型校验、异常该如何处理。即使补充的内容是“默认不校验”，也比完全空白强——这等于把不确定性显式化，而不是让生成阶段去猜。

8. 把t3code用在真实工作里的建议

t3code目前已经接入我自己的日常编码流程，用下来最大的感受是：它不适合做需要创意和架构设计的复杂任务，但在标准化、模块化的小任务上效率极高。

适合t3code发挥的场景，我总结了一下:

• 数据清洗小脚本：格式转换、过滤、去重等任务，描述清晰，规则明确
• 接口胶水代码：对接两个系统，格式转换、字段映射，套模板就能写
• CRUD接口生成：标准的路由+服务+存储结构，属于强套路化代码
• 单元测试骨架生成：给一个函数名和输入输出，生成基础的测试用例，非常节省时间

不适合的场景也很明显：

• 系统架构设计：需要综合权衡多方的决策，大模型没有那个大局观
• 极端性能优化：需要profiling、benchmark，AI生成代码通常不够精细
• 业务规则模糊的需求：需求自身矛盾，需要人脑先理清楚

如果你也想搭一个类似的个人工具，我的建议是从最简版本开始：一个接口+一个大模型API+一段Prompt，先跑通“描述转代码”，再逐步加静态检查、动态验证。不要一开始就铺开做全套，因为每个环节都有各自的坑，等你全部踩完，热情也消耗得差不多了。

9. 我个人在这次项目里最值回票价的三个判断

项目收尾之后，回过头来看，有三个判断我觉得做得最值，单独拎出来分享给所有想折腾AI编程工具的人。

第一个判断是把“静态检查”放在了“动态验证”前面。很多人觉得生成代码直接跑就行，但纯动态验证的盲区太大了——它只能告诉你这个给定的输入有没有过，不能告诉你别的输入会不会炸。静态检查先拦一遍，把低级错误在还没跑测试之前就解决掉，整个系统的失败成本大幅度降低。

第二个判断是让大模型自己产出测试样例。这看起来是偷懒，但实际上是聪明的工程取舍。因为它生成的样例跟它生成的代码天然同源，逻辑一致；如果你另写一套测试逻辑，反而会跟模型产出的内容对不上。当然，这里需要的只是“最小冒烟测试”，真正严谨的单元测试还是得人写。

第三个判断是限制修复次数。所有AI编程工具都存在的致命诱惑是：想让模型修到完美。但无限修复的边际收益递减得非常快，三轮之内修不好的，说明问题的根本不在“修”，而在于需求描述或者代码结构太离谱，重开一次反而可能更快。止损，是工程里最高频也最被低估的一个动作。

t3code还在迭代中，下一个让我头疼的问题是“长代码跨文件生成”，因为单个文件内的生成已经比较成熟了，但跨文件的项目级生成会牵涉到模块间接口对接，不是一个Prompt能搞定的。等我想出方案，再来跟各位展开聊。