企业官网建设流程全解析

项目标题: "t3code" 项目正文: 基于“Text-to-Code”思路的个人工作流项目，代号t3code，强调“Think-Translate-Test”三阶段代码生成方法论。 关键词: t3code, 文本转代码, 三阶段提示词工作流, LLM代码生成, 人机协同编程

先说说t3code这名字怎么来的。有人以为是某个开源库的代号，其实拆开就是：text（文本）、3（三阶段）、code（代码）——一句话解释，就是一套用自然语言描述需求、靠大模型分三步生成可用代码的个人工作流。我做这个项目的初衷很简单，受够了那种“让AI写一段代码，结果跑起来全是坑”的体验。后来在大量实操里总结出一套相对稳定的套路，名字就叫t3code，目前已经成了我日常开发里离不开的脚手架。

这项目不是某个框架，也不是某个插件，而是一整套和LLM协作写代码的提示词工程方法+配套脚本。核心解决三个痛点：第一，需求描述不清楚导致生成代码南辕北辙；第二，一次性生成大段代码容易逻辑断裂；第三，生成完就算完了，缺少自动验证和修复的手段。适合谁用？如果你平时已经在用ChatGPT、Claude这类工具辅助写码，但总觉得结果不稳定、时好时坏，那这套流程应该能帮上忙。它不挑语言、不挑IDE，任何地方都能套用。

1. 项目整体设计：为什么非要把“写代码”拆成三步

1.1 从一次失败的生成说起

先讲个反面案例。之前我想让模型写一个Python脚本，用来处理Excel表格里重复行合并的问题。当时我给的提示词很简单：“帮我写个脚本，合并Excel重复数据”。模型很快给出一段代码，逻辑看着也对，但一跑直接报错——原因是它默认数据是单Sheet且没有表头，而我的表头在第二行，表格里还混着合并单元格。没人怪模型，问题是需求根本没说清。

这个经历让我意识到一件事：大模型写代码，像极了一个新来的实习生。你给它模糊指引，它就给你模糊代码；你给它清晰规格，它才能交出像样的活。而现实是，大部分人在和模型协作时，既没有“需求分析”环节，也没有“验收测试”环节，直接把写代码当成了唯一一步。t3code的核心思路，就是把这个分割得稀碎的协作过程重新组织成三个清晰阶段。

1.2 三阶段各自的职责边界

t3code的设计原则非常简单：Think先于Translate，Translate之后必须Test。三个环节各有各的不可替代性——

• Think（思考）：把模糊想法变成结构化需求。产出是功能清单、输入/输出定义、边界条件、技术选型理由。这一步完全不写代码。
• Translate（翻译）：把结构化需求变成实际代码。产出是可直接运行的代码片段或文件，按模块拆解，一次只生成一个单元。
• Test（测试）：让模型自己检查代码、构造测试用例、执行验证。产出是测试报告和修复建议，需要情况下循环回Translate阶段。

很多人会觉得这多此一举，明明一条提示词就能出代码，为什么要拆三步？我的实测数据是这样的：直接生成的成功率（指无需改动即可运行的代码比例）大约只有30%-40%，而走完三阶段流程后，一次通过率能到70%甚至更高，剩下的30%也大多是小修小补。多花5分钟的思考成本，换来的是半小时以上的调试时间节省，这笔账怎么算都划算。

1.3 这套设计想避开哪些坑

拆成三步不是拍脑袋，而是针对性解决真实场景里最常踩的坑。第一个坑是上下文碎片化：很多人在对话里东一句西一句，模型根本拼不出完整需求，自然写不对代码。第二个坑是盲目信任输出：模型生成的代码表面完整，实际存在逻辑漏洞、依赖缺失或环境不匹配，等你跑到生产环境才发现。第三个坑是一次性生成过大的代码块：让模型一次性写300行，它写到后面往往会“遗忘”前面的约定，变量名漂移、函数签名不一致，都是这么来的。

t3code就是围绕这三个坑设计的。Think阶段把需求收敛到一个稳定版本，后续所有对话以此为锚点，碎片化问题直接掐断；Test阶段强制验证，把“生成完就不管了”的坏习惯改掉；Translate阶段拆模块生成，让模型每段代码都聚焦单一职责，逻辑断裂的概率自然降低。

2. 核心细节解析：Think-Translate-Test每一步到底怎么做

2.1 Think阶段：从“一句话想法”到“一页纸规格”

这一步是整个流程的命门，但很多人会跳过它，因为看起来不产代码、没有成就感。实际上，Think阶段的质量直接决定后面所有步骤的成败。我通常会让模型把需求拆成下面几个板块：

1. 项目目标：一句话说清这个程序要解决什么问题，给谁用；
2. 功能清单：功能列表，每项前面标注优先级（P0必须、P1应该、P2可以）；
3. 输入/输出定义：程序接收什么格式的数据，输出什么格式的结果，文件路径、字段名、编码都要写明白；
4. 边界情况：空数据、错误格式、超大文件、网络中断等异常场景如何处理；
5. 技术栈约束：用什么语言、哪些库、是否允许外部依赖、目标运行环境。

举个例子。拿前面那个Excel合并需求来说，Think阶段的产出应该是这样的：

项目目标：对多个Excel文件中的重复行进行合并统计，输出汇总表。 功能清单： - P0：读取指定目录下所有.xlsx文件 - P0：识别重复行（以“订单号”列作为唯一键） - P0：合并重复行并累加“数量”列 - P1：生成汇总报告，保留每个文件的单独统计 - P2：支持通过命令行参数传入目录路径 输入/输出定义： - 输入：文件夹路径下所有.xlsx文件，每个文件第一行是表头，数据从第二行开始 - 输出：汇总表.csv，包含订单号、总数量、来源文件列表 边界情况： - 文件为空：跳过并输出警告 - 多个文件存在相同订单号：合并数量，来源文件列用“|”分隔 技术栈约束：Python 3.10+，仅允许使用pandas和标准库，不允许改动原始文件

这页纸写下来以后，你会发现后面让模型写代码变得非常轻松。因为模型不再需要替你猜需求，它只需要把你给出的规格翻译成代码。

这里有一个小技巧：让模型在Think阶段结束时，自己把规格整理成一份markdown格式的需求文档，后续所有对话里都把这文档粘贴进去作为上下文锚点。这样做的好处是，哪怕对话中途换了个上下文窗口，模型仍然能基于同一份需求理解后续指令。

2.2 Translate阶段：拆模块、定契约、逐个击破

规格文档到手后，别急着说“好了，写代码吧”。Translate阶段的第一个动作是拆分模块。即使是一个几十行的小脚本，我也建议拆成至少两个部分：入口逻辑和核心处理逻辑。比如上面那个Excel需求，可以拆成“文件读取模块”“去重合并模块”“报告输出模块”“命令行入口”。

每个模块的生成建议遵循一个固定模板：

模块目标：一句话描述这个模块做什么 依赖关系：这个模块调用了哪些函数/数据，被谁调用 接口定义：函数签名、输入参数类型、返回值类型 实现代码：核心逻辑实现

不是说要给模型看这么多，而是你内心要有这个结构。实际操作时，我给模型的Translate指令通常是这样的：

基于上方需求文档，现在只实现“文件读取模块”。要求提供一个函数list_excel_files(dir_path: str) -> list，返回目录下所有.xlsx文件的完整路径列表。仅输出这个函数的代码，不需要调用示例，不需要额外解释，不要修改其他模块。

注意三个关键约束：“只实现”、“仅输出”、“不要修改”。这三个词能极大降低模型发挥的自由度，让它老老实实按需求办事。每次只生成一个函数或一个类，生成完立即进入下一轮，不要让它顺手写一个完整脚本。

等所有模块都生成完毕以后，再进行一次集成——把所有模块代码拼到一个文件里（或者按需拆成多个文件），然后发给模型，让它做一次“契约检查”：检查函数调用关系是否一致、参数命名是否统一、返回值和调用方预期是否匹配。这一轮通常能发现不少因为分模块生成而产生的接口不一致问题。

2.3 Test阶段：让代码自己证明自己

Translate阶段不代表流程结束，真正拉开差距的是最后的Test环节。很多人拿到模型代码，本地跑一遍发现“唉能跑通”，就以为万事大吉了。但在t3code里，跑通只是最低标准。我的Test阶段包含三层验证：

1. 静态自检：让模型阅读自己刚生成的代码，检查潜在逻辑错误、未处理异常、变量命名冲突。可以给一个简单的提示：“假设你是Code Reviewer，以下代码有哪些问题会导致在Python 3.10环境运行失败？请指出并直接给出修复版代码。”

2. 测试用例生成：这一步尤其重要。让模型根据需求文档中的边界情况，生成对应测试用例。不是让模型生成测试代码，而是让模型输出一组“输入-期望输出”的映射表，然后你手动或让模型写成一个测试脚本跑。

3. 运行验证：在本地环境实际执行。如果报错，不要让模型直接盲改，而是把完整报错堆栈贴回去，附上需求文档中对应的部分，让它分析原因后给出修复方案。修复完再跑，循环往复。

我用一个简单的例子说明测试用例长什么样。假设上面的Excel合并程序已经写好，那测试用例至少应该覆盖：

测试用例1：空目录输入 -> 程序正常退出，输出警告信息 测试用例2：单文件单行数据 -> 输出表与输入一致 测试用例3：三个文件存在相同订单号 -> 数量正确累加，来源文件列正确合并 测试用例4：文件包含非UTF-8编码 -> 抛出明确错误提示，而非堆栈乱码

这些用例不一定全部写成自动化脚本，但至少要在人机对话里逐条过一遍。你会发现，很多“跑通了”的代码，在边界用例面前立刻原形毕露。

2.4 一个人机协同时钟：什么时候该信模型，什么时候该抢回键盘

使用t3code久了以后，我总结出一个经验：模型不是所有场景都适合参与。涉及复杂业务规则的算法逻辑（比如供应链排程、计费规则），模型容易理解错业务语义；涉及高性能计算的底层代码（比如并发锁、内存池），模型生成的代码通常不够精细。这两种情况，Think阶段的产出依然有用，但Translate和Test阶段你得自己上手。反过来，批处理脚本、数据处理管线、原型代码、一次性迁移脚本，这些场景t3code的效率和稳定度远远超过纯人工。

我的判断标准很简单：如果写错一次的代价是数据损坏、资损或生产故障，那核心逻辑必须人来写；如果写错一次的代价是可以快速回滚、不影响业务，那完全可以交给模型。用这个标准划一条线，既不会过度依赖AI，也不会因为不放心而拒绝所有效率红利。

3. 实操过程：从零搭一个t3code工作流，以“自动重命名文件脚本”为例

3.1 准备阶段：环境与模型选择

纸上谈兵没用，我直接走一遍完整流程。这次我选的场景是“批量重命名文件”的小工具——具体需求是这样的：一个文件夹里放了大量照片，文件名是“IMG_20230101_123456.jpg”，我想把它改成“2023-01-01_12.34.56.jpg”格式。这个需求足够典型，有正则、有时间解析、有文件操作、有异常处理，很适合演示。

环境很简单：一台装了Python 3.11的电脑，用免费的LLM在线聊天窗口即可，不要求本地部署。个人经验，在线模型和本地模型在t3code流程上的表现差距不大，关键是提示词的质量，而不是模型参数量。当然，如果你用的是DeepSeek、ChatGPT或Claude，效果会好一个档次，推理能力强的模型在Think和Test阶段更少“跑偏”。

3.2 第一阶段实操：写清楚Think需求书

我把原始需求发给模型前，先按t3code的格式自己列了个骨架：

项目目标：批量重命名指定目录下的jpg图片，原文件名为IMG_YYYYMMDD_HHMMSS.jpg，目标文件名为YYYY-MM-DD_HH.MM.SS.jpg 功能清单： - P0：扫描指定目录下所有.jpg文件 - P0：用正则匹配旧文件名，提取年月日时分秒 - P0：按规则重新格式化文件名；若文件名不匹配，则跳过并记录 - P1：输出重命名报告（成功数、失败数、失败原因） - P1：支持--dry-run参数，只打印将改成的名字，不实际执行 边界情况： - 文件重名：自动加后缀_1、_2 - 文件正在被其他程序占用：跳过并记录 - 文件名不符合正则：跳过不报错 技术栈约束：Python标准库（os, re, pathlib, datetime），不安装第三方依赖

然后我把这个骨架发给模型，让它“扩展成一份完整的需求规格书，并用markdown格式输出”。这一步的作用一是让模型帮我查漏补缺（比如它会提醒我考虑子目录递归、隐藏文件等），二是后续的Translate阶段可以直接把规格书粘贴回上下文，保持信息一致。模型输出的规格书里果然补了一条我没注意的：“如果原文件名存在AM/PM标识，需要转换为24小时制”——虽然我们的实际数据用不到，但这种补全提醒非常有价值。

3.3 第二阶段实操：按模块生成代码并拼装

拿到规格书后，我把规格书拷贝到新的对话窗口里，开始Translate阶段。不要在原对话窗口继续生成代码，因为前面Think阶段的对话会占用大量上下文，拖慢响应速度且容易干扰代码生成。新窗口第一条消息就是：规格书全文 + “请只实现一个函数extract_datetime_from_filename(filename: str)，输入文件名，输出一个datetime对象，如果无法解析则返回None。仅输出函数代码。”

模型给出了代码：

import datetime import re def extract_datetime_from_filename(filename: str): pattern = r"^IMG_(\d{4})(\d{2})(\d{2})_(\d{2})(\d{2})(\d{2})\.jpg$" m = re.match(pattern, filename, re.IGNORECASE) if not m: return None year, month, day, hour, minute, second = map(int, m.groups()) try: return datetime.datetime(year, month, day, hour, minute, second) except ValueError: return None

然后下一个模块“生成新文件名”：

def generate_new_filename(dt: datetime.datetime, counter: int = 0) -> str: base = f"{dt.strftime('%Y-%m-%d_%H.%M.%S')}" if counter: return f"{base}_{counter}.jpg" return f"{base}.jpg"

再下一个模块“重命名主逻辑”。每个模块独立生成、独立审查，最后我手动把所有代码拼到一个文件里，粘贴给模型做契约检查。模型发现了一个我没想到的问题：如果原目录里已经有“2023-01-01_12.34.56.jpg”，而新文件名恰好也叫这个，直接os.replace会覆盖原文件。这个bug在分模块时完全看不出来，集成时模型一眼就察觉到了。我补了一个“检查目标是否存在，存在则加后缀”的逻辑，才算过关。

3.4 第三阶段实操：测试用例设计、运行失败与修复

代码拼装完成后，我不着急跑，先让模型生成了测试用例表：

输入文件名 期望新文件名 说明 IMG_20230101_123456.jpg -> 2023-01-01_12.34.56.jpg 正常情况 IMG_20231231_235959.jpg -> 2023-12-31_23.59.59.jpg 跨年边界 IMG_20230230_120000.jpg -> 跳过，解析失败 无效日期（2月30日） random_file.jpg -> 跳过，不匹配 未匹配正则 IMG_20230101_123456_1.jpg -> 跳过，不匹配 多了一个后缀

然后本地写测试脚本跑。第一个用例正常，第二个正常，第三、四个都成功跳过，看起来全过了。但我用实际数据测试时翻车了——真实数据里有几张文件名是“IMG_20230101_123456 (1).jpg”，这是相机重复照片自动加的后缀，模型没预见到。当时的正则没覆盖这种情况，结果这几张照片跳过了重命名，没有报错，但也没处理。这让输出报告里的“失败原因”这列几乎没有意义，因为所有失败都显示“未匹配”。

我的修复方式有两种，一种是改正则容纳“ (1)”这种额外后缀并忽略它，一种是调整Think阶段需求文档里的边界情况说明。我选了前者，同时把这个新边界情况补充回了需求文档。这也是t3code的一个重要原则：每次Test阶段发现的边界情况，都要回写进Think阶段的规格书里，这样下次遇到类似需求时，模型就不会再犯同一个错误。

4. 工具链选型与参数调优：哪些配置让t3code更好用

4.1 模型怎么选：快与聪明之间的取舍

t3code跑了一段时间，我用过不同模型，也整理了一张选型参考表：

个人经验，如果你的日常任务以小型脚本为主，完全没必要为t3code购买旗舰模型。中档模型在t3code流程下已经能输出相当可用的代码，因为流程本身补足了模型的短板——Think阶段帮你把需求想清楚，Test阶段帮你把问题揪出来。旗舰模型更像一个经验丰富的搭档，能主动提出潜在风险，但它的优势在复杂项目里才明显。我平时主力用的还是中档模型，只在处理棘手集成问题时才切换到旗舰模型。

4.2 提示词模板细节：几个“暗坑”要避开

用t3code的过程中，我踩过不少提示词层面的坑，说几个最典型的：

坑1：不要让模型“一步到位”。直接说“写一个完整的XX脚本”，模型倾向一次性输出大量代码，行数和上下文一长，质量直线下降。解决办法永远是拆模块。

坑2：不要用“等等”这类模糊词汇。比如“先用正则匹配，等等然后提取时间”，模型对“等等”的解读可能各不相同。宁可啰嗦也要把每一步都列出来，要么就交给它自己先Think。

坑3：修复bug时不要只扔报错。你得同时给代码上下文和需求文档。很多人报错信息一贴就完事，模型看不到全貌就只能猜，改出来的代码往往只是“这次恰好不报错”，换个输入又炸。t3code的做法是每次修复请求都携带：需求文档 + 当前完整代码 + 完整报错堆栈 + 触发报错的输入数据。这四样东西齐了，模型修复的精准度会翻倍。

4.3 超参数和运行配置：温度、输出长度、轮次上限怎么设

如果你的模型是通过API调用的，还有几个参数可以调。我自己常用的配置是这样的：

{ "temperature": 0.3, "top_p": 0.9, "max_tokens": 4096, "presence_penalty": 0.0, "frequency_penalty": 0.0 }

温度设低一点（0.2-0.4）：代码生成任务需要确定性，温度太高模型容易在变量命名、代码风格上过度“发挥”，导致代码不稳定。有人担心低温会降低创意性，但在代码生成场景里，“创意”往往等于“意外bug”。max_tokens要够长：如果上限太短，模块生成到一半被切断，输出直接废掉。我设定的4096个token足够覆盖绝大多数单模块代码。另外，每次对话轮次建议控制在12轮以内。超过这个数，上下文里堆积太多历史信息会干扰模型对最新指令的执行，这时候宁可新建一个对话窗口，重新粘贴需求文档和当前代码状态。

4.4 工作流脚本化：用Python封装一个cli入口

用久了你就会想：能不能把这些流程固化下来，别每次手动复制粘贴？我后来写了一个大概50行的小工具，把需求文档保存成markdown文件，然后用一个newsession脚本自动打开新对话并填充提示词。当然模型不支持跨平台API的时候这个脚本用处有限，但如果你用的是支持API的模型，这个思路可以完整落地。

import subprocess import sys from pathlib import Path def new_session(spec_file: str): spec = Path(spec_file).read_text(encoding="utf-8") prompt = f"""你是一名资深软件工程师。下面是一份需求文档，请严格按照其中的规格进行实现。 {spec} 现在请从第一步开始，完成Think阶段，即审查需求文档，找出所有遗漏、矛盾和风险，输出修订后的最终规格书。如果文档已经足够清晰，请直接回复“需求文档完整，可以进入Translate阶段”。""" print("已生成新会话提示词，请复制以下内容到模型窗口：\n") print(prompt) if __name__ == "__main__": new_session(sys.argv[1])

原理非常简单：把固定的提示词模板和需求文档拼在一起，生成一段可直接粘贴的内容。后续还可以扩展成调用API自动完成整个流程，但手工方式其实已经能省下80%的复制粘贴时间。

5. 常见问题与排查技巧实录：t3code运行一年踩过的12个坑

5.1 生成代码没问题，但一运行就报“模块不存在”

这是出现频率最高的一个问题，尤其是让模型用了第三方库但没在需求文档里声明。比如我们前面严格约束“只用标准库”，那代码里就不会出现pandas，但如果Think阶段没约束，模型看到“处理CSV”就惯性地import pandas，你本机正好没装就当场报错。

排查思路很简单：一看到ModuleNotFoundError，先别急着让模型修。直接回到Think阶段的需求文档，确认技术栈约束是否明确写清。如果写了，说明模型没遵守约束，这时要让模型“重读需求文档的技术栈约束部分，然后修改代码”；如果没写，说明是你自己的需求文档漏了，补上后重新Translate。

5.2 模型每次生成的代码风格都不一样，变量命名飘忽不定

这个问题的根源通常在Translate阶段没有给“风格锚点”。我的解决办法是在需求文档里加一段“代码风格约定”，哪怕只有一行：“使用snake_case命名、函数前加类型注解、私有函数以下划线开头”。就这么简单的一行，模型的输出风格立刻稳定很多。不只是命名，换行、缩进、注释密度这些都可以在风格约定里固定下来。

5.3 上下文越来越长，模型开始“遗忘”早期需求细节

对话轮次多了以后，模型对早期内容的理解力会下降。典型表现是：明明需求文档里写了“输入文件是UTF-8编码”，生成的代码里却用了默认编码。这不是模型智商问题，是上下文注意力天然向近期内容倾斜。

我的做法是阶段隔离：Think阶段的对话只做思考，完成后立刻把需求文档复制出来；Translate阶段新开对话，只粘贴需求文档+当前模块任务；Test阶段再新开对话，只粘贴需求文档+当前完整代码+测试失败信息。三个阶段的对话互不相通，每个对话都保持上下文简短。这样做还有个好处，每阶段的对话都能作为单独的历史记录存档，方便回溯。

5.4 模型生成的测试用例全是“正常情况”，边界测试形同虚设

你让模型“生成测试用例”，它默认给你10个都是有效输入、预期输出——这种测试对发现问题几乎没用。要解决这个问题，得在指令里把边界情况列出来。比如我在Test阶段的提示词里固定加一句：“请覆盖以下场景：空输入、超长输入、非法字符、特殊字符、重复调用、权限不足、文件不存在。”这样列出来以后，模型的测试用例才会真正有意义。

5.5 修复A bug后引入B bug，越改越乱

这种情况很像传统开发里的“回归缺陷”。模型在你指出问题后只盯着问题区域改，忽略了周围代码的依赖关系。我的经验是：每次修复后，不要直接进入下一个模块，而是让模型先跑一遍该模块的单元测试。如果t3code集成到了真实的CI流程，还能设定为“修复后要求全部测试通过才能继续”。如果只是聊天窗口协作，那至少在对话里让模型明确声明“本次修改不会影响其他模块的接口”并给出理由。

5.6 本地环境能跑，换一台机器/换个系统就跑不了

这是环境一致性问题，最典型的包括：文件路径分隔符Windows和Linux不一样、第三方库版本差异、Python版本差异。t3code在需求文档里应该增加一个“目标运行环境”字段，写清楚操作系统、Python版本、依赖库版本号。更保险的做法是，代码生成后让模型为它配一个requirements.txt或者使用标准库避免依赖。在t3code里，我默认优先用标准库，第三方库必须要在Think阶段获得“批准”才能使用。

5.7 “这个代码好像对，但我说不清哪里不对”

这是所有问题里最棘手的，因为模型没报错、代码也能跑，但输出结果和预期总有微妙差别。我的排查方法是：让模型为关键函数写“解释型日志”。不是print大法，而是让它用文字描述每个关键步骤完成了什么、产生了什么中间结果。通常跑一轮这种带日志的版本，你就立刻能发现是哪一步的逻辑和预期不一致，然后带着问题回去精准定位。

5.8 模型直接拒绝写代码，说自己“不能提供完整实现”

这个偶尔出现在一些有安全限制的模型上。对付办法不是和它争论，而是把需求拆得更小。比如“实现一个函数，判断字符串是否为合法日期”，绝大多数模型不会拒绝这种原子化的函数请求。如果连函数级的请求都被拒，那就换成“用文字描述实现思路”，然后自己写，让模型只做Code Review。用t3code久了你会发现，模型越用越听话，还是因为我更懂怎么给它派活了。

5.9 Think阶段规格书写得太细，变成过度设计

凡事都有度。我见过有的人把需求文档写得像详细设计说明书，连某个函数的内部循环怎么写都规定了。这就等于放弃了模型的最大价值——它擅长在给定约束下寻找你可能没想到的实现方案。规格书应该约束“做什么”和“边界是什么”，而不是约束“具体怎么实现”。如果你发现自己在Think阶段已经开始写代码逻辑了，停一停，把它留到Translate阶段让模型发挥。

5.10 多轮对话后模型开始“合理化”自己的错误

这是最让我哭笑不得的场景：我对着一份明显有bug的代码问“这个边界会不会出问题”，模型回答“不会，因为前面已经处理过了”，但代码里实际没有那段处理。模型在生成解释时，倾向于补全自己认为“应该存在”的逻辑。所以遇到需要模型做判断时，我总是要求它引用具体的代码行号或函数名作为依据，不接受“应该是”这种口头保证。

5.11 生成了大量不安全的代码，比如路径硬编码、明文密码

模型默认会图省事把配置信息写死在代码里，这在原型验证时无所谓，但一旦进入生产环节就是隐患。t3code解决这个问题的思路，是在Think阶段的规格里设置一条“配置管理约定”：所有可变的参数必须抽出来放在配置区。比如文件扫描路径、日志级别、输出目录这些，都做成变量，不允许写死在函数体内。这样生成出来的代码天然具备一定可维护性。

5.12 测试全过，但真实业务数据一跑就出问题

这是最接近真实工作场景的坑。根源在于测试数据是模型自己构造的，天然存在“同构偏差”——模型构造的数据符合模型自己的假设，而真实的业务数据往往不在这些假设里。我的对策是：真实数据优先作为测试输入。如果是处理文件的脚本，就丢一个真实文件进去跑；如果是跑SQL，就把真实schema给模型看。t3code里有一个原则叫“不需要测试皇后的完美覆盖，但要保证真实场景的第一个数据文件不炸”。

6. 我对t3code的长期使用体会与后续扩展思路

整套流程跑了大半年，最大的变化其实不是代码生成质量，而是我的工作习惯。以前接到一个任务，第一反应是撸起袖子写代码；现在第一反应是打开模板写规格书。这个转变一开始很别扭，总觉得自己在写文档而不是写程序，但时间久了发现写规格书的那几分钟，实际是在逼自己想清楚需求。很多以前写到一半才发现的问题，现在在Think阶段就暴露了。

关于后续扩展，我眼下在尝试两个方向。一个是把t3code流程固化成团队规范，做一个简单的模板仓库，团队成员提交需求时统一用这个模板描述，这样无论谁用模型辅助开发，前提条件都是一致的。第二个是让Test阶段更自动化——把需求文档里的边界情况自动翻译成pytest测试骨架，再结合CI让模型生成的代码每次提交都跑一遍自动化测试。这两个方向都还在试验中，等跑顺了再单独写一篇分享。

最后分享一个压箱底的小技巧。t3code跑久了，你会积累一堆“好用的提示词片段”，比如“按需求文档检查遗漏并输出修订版”“只输出函数代码不要解释”“这个测试用例没覆盖到边界条件”等等。我建了一个纯文本文件专门存这些片段，按场景分类，用时直接复制。日积月累，这玩意儿比任何付费prompt库都顺手，因为每一句都是你被真实项目毒打后提炼出来的。建议你也这么做起来，攒出自己的“t3code片段库”。