現(xiàn))
先聊一個(gè)現(xiàn)象現(xiàn)在很多同學(xué)使用 LLM 生成代碼已經(jīng)習(xí)慣了“描述需求 → 拿到大段代碼 → 復(fù)制 → 調(diào)試 → 再讓模型修復(fù)”的循環(huán)。這種開(kāi)發(fā)方式有一個(gè)很形象的說(shuō)法叫 vibe coding也就是只憑“感覺(jué)”讓大模型把代碼寫(xiě)出來(lái)自己負(fù)責(zé)驗(yàn)收和兜底。它的效率確實(shí)很高但真正的團(tuán)隊(duì)項(xiàng)目或者正式環(huán)境里不驗(yàn)證生成結(jié)果、不固定生成過(guò)程、讓模型反復(fù)輸出風(fēng)格不穩(wěn)定的代碼很容易埋下不可維護(hù)的隱患。本文要聊的 Sif 1.0正是這種背景下出現(xiàn)的一個(gè)很有意思的嘗試。它的核心不是“讓 LLM 生成代碼”而是讓 LLM 去控制一個(gè) deterministic coder確定性編碼器。也就是說(shuō)把大模型的角色從“手寫(xiě)代碼的工具人”變成“下指令、做決策、驗(yàn)收產(chǎn)物的指揮官”同時(shí)把真正產(chǎn)生代碼的部分交給可預(yù)測(cè)、可重復(fù)、可回歸的確定性組件來(lái)執(zhí)行。這篇文章會(huì)圍繞 Sif 1.0 的設(shè)計(jì)思路展開(kāi)以下內(nèi)容什么是 deterministic coder它和普通 AI 生成代碼有什么區(qū)別Sif 1.0 的整體架構(gòu)是怎樣的LLM 在其中扮演什么角色如何用 Python 親手搭建一個(gè)“LLM 控制確定性編碼器”的最小示例實(shí)際使用中常見(jiàn)的問(wèn)題、排查思路與工程化建議。無(wú)論你是對(duì) LLM Agent 感興趣的開(kāi)發(fā)者還是正在做 AI 編程工具、內(nèi)部代碼生成平臺(tái)這篇文章都能提供一個(gè)比較完整的參考。1. 背景與核心概念1.1 從 vibe coding 到 LLM AgentVibe coding 這個(gè)詞這幾年很流行它的核心特征是開(kāi)發(fā)者不再逐行編寫(xiě)代碼而是用自然語(yǔ)言描述意圖把實(shí)現(xiàn)細(xì)節(jié)交給 LLM 完成。這種方式在快速原型、腳本編寫(xiě)、臨時(shí)工具開(kāi)發(fā)上效率極高特別適合驗(yàn)證想法。但它的缺點(diǎn)也很明顯輸出不穩(wěn)定同樣的提示詞多次生成結(jié)果可能不同質(zhì)量不可控模型可能一本正經(jīng)地生成有邏輯漏洞的代碼回歸困難項(xiàng)目后期修復(fù)一個(gè) bug可能把另一個(gè)模塊改壞審計(jì)困難無(wú)法追溯到某段代碼的生成依據(jù)和驗(yàn)證過(guò)程。正因?yàn)檫@些問(wèn)題很多團(tuán)隊(duì)開(kāi)始把目光從“讓 LLM 直接寫(xiě)代碼”轉(zhuǎn)向“讓 LLM 編排代碼生成流程”。LLM 的任務(wù)不再是吐出大段代碼而是理解需求、拆分任務(wù)、選擇合適的確定性組件、傳遞參數(shù)、檢查輸出結(jié)果。這個(gè)方向逐漸演變成 LLM Agent 的一個(gè)重要分支。1.2 deterministic coder 是什么Deterministic coder即確定性編碼器指的是一類(lèi)“在相同輸入條件下輸出完全可復(fù)現(xiàn)”的代碼生成組件。它的特點(diǎn)包括有明確的輸入輸出契約不依賴(lài)概率采樣生成結(jié)果可回歸驗(yàn)證執(zhí)行過(guò)程可以通過(guò)日志完整追蹤通?；谀０?、DSL、代碼生成器或編譯機(jī)制實(shí)現(xiàn)。舉個(gè)最簡(jiǎn)單的例子一個(gè)根據(jù)數(shù)據(jù)庫(kù)表結(jié)構(gòu)生成 Mapper 代碼的工具輸入是表結(jié)構(gòu) JSON輸出是完整的 Java Mapper 文件。只要輸入不變輸出永遠(yuǎn)相同。這就是典型的 deterministic coder。1.3 Sif 1.0 的定位Sif 1.0 的核心思路是用 LLM 來(lái)控制一個(gè)或者多個(gè) deterministic coder組成一套“LLM 做決策、確定性組件做執(zhí)行”的代碼生成流水線(xiàn)。如果把它和傳統(tǒng) vibe coding 做對(duì)比會(huì)更清晰維度傳統(tǒng) vibe codingSif 1.0 思路LLM 角色直接生成最終代碼輸出任務(wù)計(jì)劃、參數(shù)和校驗(yàn)結(jié)果代碼來(lái)源LLM 概率采樣確定性編碼器按計(jì)劃生成可重復(fù)性不穩(wěn)定同一計(jì)劃產(chǎn)出相同代碼質(zhì)量保證靠人工審查計(jì)劃校驗(yàn) 生成結(jié)果校驗(yàn) 人工抽查適用場(chǎng)景原型驗(yàn)證、腳本工具工程化代碼生成、遺留系統(tǒng)改造Sif 1.0 不把 LLM 當(dāng)成“萬(wàn)能的代碼生成器”而是把 LLM 放在一個(gè)更合理的位置理解模糊業(yè)務(wù)需求轉(zhuǎn)換成結(jié)構(gòu)化的代碼生成指令再把指令交給專(zhuān)門(mén)負(fù)責(zé)某一類(lèi)代碼產(chǎn)物的確定性生成器。這種設(shè)計(jì)帶來(lái)的價(jià)值很直接代碼風(fēng)格一致生成過(guò)程可審計(jì)回歸測(cè)試可以自動(dòng)化不依賴(lài)某一個(gè)大模型的編碼能力降低模型替換成本。2. Sif 1.0 的架構(gòu)與設(shè)計(jì)思路要理解 Sif 1.0需要先拆解它的架構(gòu)分層。它并不是一個(gè)單一的庫(kù)或模型而是一套“控制框架”核心組件包括三個(gè)部分LLM 控制層、確定性編碼引擎、驗(yàn)證與反饋層。2.1 LLM 控制層LLM 控制層是系統(tǒng)的“大腦”。它負(fù)責(zé)接收用戶(hù)自然語(yǔ)言需求分析需求拆解為多個(gè)子任務(wù)從確定性編碼器注冊(cè)表中選擇合適的生成器為每個(gè)生成器生成結(jié)構(gòu)化參數(shù)對(duì)生成結(jié)果進(jìn)行初步評(píng)估根據(jù)驗(yàn)證結(jié)果決定是否重新調(diào)整參數(shù)。這一層的關(guān)鍵不是讓 LLM 直接寫(xiě)代碼而是讓 LLM 輸出結(jié)構(gòu)清晰的中間計(jì)劃。例如用戶(hù)說(shuō)“幫我生成一個(gè)用戶(hù)管理的 REST 接口”LLM 并不需要直接輸出 Controller、Service、Mapper 的代碼而是應(yīng)該輸出類(lèi)似這樣的計(jì)劃{ tasks: [ { generator: rest_controller_generator, params: { entity: User, fields: [id, name, email, created_at], operations: [list, get, create, update, delete] } }, { generator: mybatis_mapper_generator, params: { entity: User, table: t_user, primary_key: id } } ] }這個(gè) JSON 是可控的。LLM 只負(fù)責(zé)理解需求并填充結(jié)構(gòu)化參數(shù)不負(fù)責(zé)生成大段代碼。這樣一來(lái)LLM 的“犯錯(cuò)空間”被大幅壓縮。2.2 確定性編碼引擎編碼引擎由一組 deterministic coder 組成。每個(gè) coder 都只負(fù)責(zé)一種特定類(lèi)型的代碼產(chǎn)物并且是純函數(shù)式的輸入?yún)?shù) → 輸出代碼。常見(jiàn)的 deterministic coder 類(lèi)型包括REST 接口生成器輸入實(shí)體定義輸出 Controller數(shù)據(jù)訪問(wèn)層生成器輸入表結(jié)構(gòu)輸出 Mapper/RepositoryDTO/VO 生成器輸入字段定義輸出數(shù)據(jù)類(lèi)配置類(lèi)生成器輸入配置項(xiàng)輸出 YAML/properties數(shù)據(jù)庫(kù)遷移腳本生成器輸入變更描述輸出版本化 SQL。這些生成器通常使用模板引擎、代碼模型或 DSL 實(shí)現(xiàn)。它們必須是確定性的——這不僅是工程需求也是 Sif 1.0 這個(gè)名字想表達(dá)的核心價(jià)值LLM 負(fù)責(zé)“品味”確定性引擎負(fù)責(zé)“穩(wěn)定”。2.3 驗(yàn)證與反饋層驗(yàn)證層是最容易被忽略、但實(shí)際項(xiàng)目中最重要的部分。Sif 1.0 中LLM 輸出計(jì)劃后、確定性組件生成代碼后都會(huì)經(jīng)過(guò)驗(yàn)證環(huán)節(jié)計(jì)劃校驗(yàn)參數(shù)缺失、類(lèi)型錯(cuò)誤、字段不存在生成結(jié)果校驗(yàn)語(yǔ)法檢查、編譯檢查、單元測(cè)試回歸校驗(yàn)與歷史生成結(jié)果對(duì)比防止意外變更人工評(píng)審最終由開(kāi)發(fā)人員確認(rèn)。驗(yàn)證失敗時(shí)反饋信息會(huì)回流到 LLM 控制層由 LLM 修正計(jì)劃。這就是一個(gè)完整的閉環(huán)。這樣設(shè)計(jì)的另一個(gè)好處是模型可以被替換。今天用 GPT-4明天換成其他模型只要它還能輸出符合約定的計(jì)劃 JSON整個(gè)系統(tǒng)就能繼續(xù)工作。確定性編碼引擎完全不受模型升級(jí)影響。3. 環(huán)境準(zhǔn)備與版本說(shuō)明在動(dòng)手寫(xiě)示例之前先說(shuō)明運(yùn)行環(huán)境。根據(jù)多個(gè)實(shí)際項(xiàng)目經(jīng)驗(yàn)Sif 這類(lèi)“LLM 確定性編碼器”的組合并不依賴(lài)特定云服務(wù)只要本地能調(diào)用 LLM API 即可。本文示例的開(kāi)發(fā)環(huán)境如下操作系統(tǒng)Windows 10 / macOS / Linux 均可Python3.10依賴(lài)庫(kù)openai、pydantic、jinja2、pyyamlLLM 接口兼容 OpenAI API 格式的服務(wù)或本地部署模型IDEVS Code / PyCharm或直接用命令行。這里需要特別強(qiáng)調(diào)不同項(xiàng)目的依賴(lài)版本差異較大如果你本地的 openai 庫(kù)版本較新部分 API 參數(shù)可能發(fā)生變化。本文示例代碼以“配置 base_url api_key”的方式調(diào)用兼容大部分 OpenAI 兼容接口。如果你沒(méi)有可直接使用的 LLM API也可以先用一個(gè)小型本地模型替代只要它支持 JSON 格式輸出。下面所有示例都把 LLM 輸出嚴(yán)格約束為 JSON方便后續(xù)解析。建議創(chuàng)建一個(gè)獨(dú)立的虛擬環(huán)境python -m venv sif-demo source sif-demo/bin/activate # Windows 使用 sif-demo\Scripts\activate pip install openai pydantic jinja2 pyyaml項(xiàng)目結(jié)構(gòu)建議如下sif-demo/ ├── main.py # 入口組合控制層和生成引擎 ├── coder/ │ ├── __init__.py │ ├── registry.py # 確定性編碼器注冊(cè)表 │ ├── rest_coder.py # REST 接口生成器 │ └── model_coder.py # 數(shù)據(jù)類(lèi)生成器 ├── llm/ │ ├── __init__.py │ ├── controller.py # LLM 控制層 │ └── prompts.py # 提示詞模板 ├── plans/ │ └── plan.json # LLM 輸出的中間計(jì)劃 └── output/ # 生成的代碼輸出目錄不用完全照搬這個(gè)結(jié)構(gòu)但建議保持“控制器、注冊(cè)表、生成器”三部分分離。4. 實(shí)戰(zhàn)讓 LLM 驅(qū)動(dòng)確定性代碼生成器下面我們動(dòng)手實(shí)現(xiàn)一個(gè)最小可運(yùn)行的 Sif 1.0 流程。為了讓例子更直觀我會(huì)讓 LLM 根據(jù)一段自然語(yǔ)言需求輸出一個(gè) JSON 計(jì)劃然后由兩個(gè) deterministic coder 分別生成 Python 數(shù)據(jù)類(lèi)和 REST 接口骨架。4.1 定義確定性編碼器先寫(xiě)一個(gè)基礎(chǔ)的生成器抽象。這里使用一個(gè)很簡(jiǎn)單的接口每個(gè)生成器內(nèi)部實(shí)現(xiàn)generate(params) - str方法返回代碼字符串。# 文件路徑coder/base.py from abc import ABC, abstractmethod from typing import Any, Dict class BaseCoder(ABC): 確定性編碼器抽象基類(lèi) name: str base abstractmethod def generate(self, params: Dict[str, Any]) - str: 根據(jù)參數(shù)生成代碼必須保證相同參數(shù)產(chǎn)生相同輸出 pass接下來(lái)實(shí)現(xiàn)一個(gè)數(shù)據(jù)類(lèi)生成器。它的輸入是實(shí)體名稱(chēng)和字段列表輸出是 Python dataclass。# 文件路徑coder/model_coder.py from typing import Any, Dict, List from coder.base import BaseCoder class ModelCoder(BaseCoder): 生成 Python dataclass 的確定性編碼器 name model_generator def generate(self, params: Dict[str, Any]) - str: entity: str params[entity] fields: List[Dict[str, str]] params[fields] lines [from dataclasses import dataclass, ] lines.append(fdataclass) lines.append(fclass {entity}:) if not fields: lines.append( pass) else: for field in fields: fname field[name] ftype field[type] lines.append(f {fname}: {ftype}) return \n.join(lines) \n再實(shí)現(xiàn)一個(gè) REST 接口生成器把實(shí)體名轉(zhuǎn)換成 Controller 骨架。這里不依賴(lài)任何 Web 框架只是生成一個(gè)類(lèi)體現(xiàn)確定性代碼生成的過(guò)程。# 文件路徑coder/rest_coder.py from typing import Any, Dict, List from coder.base import BaseCoder class RestCoder(BaseCoder): 生成 REST 接口骨架的確定性編碼器 name rest_controller_generator def generate(self, params: Dict[str, Any]) - str: entity: str params[entity] base_path: str params.get(base_path, f/{entity.lower()}) lines [f# {entity} REST Controller, ] lines.append(fclass {entity}Controller:) lines.append(f base_path {base_path!r}) lines.append() lines.append( def list(self):) lines.append( raise NotImplementedError) lines.append() lines.append( def get(self, id):) lines.append( raise NotImplementedError) lines.append() lines.append( def create(self, data):) lines.append( raise NotImplementedError) lines.append() lines.append( def update(self, id, data):) lines.append( raise NotImplementedError) lines.append() lines.append( def delete(self, id):) lines.append( raise NotImplementedError) return \n.join(lines) \n這兩個(gè)生成器都是完全確定性的輸入相同參數(shù)輸出永遠(yuǎn)一致。它們甚至不依賴(lài) LLM。4.2 實(shí)現(xiàn)注冊(cè)表接下里把生成器放進(jìn)注冊(cè)表。注冊(cè)表的作用是讓 LLM 控制層按照名字查找生成器而不需要感知具體類(lèi)。# 文件路徑coder/registry.py from coder.base import BaseCoder from coder.model_coder import ModelCoder from coder.rest_coder import RestCoder class CoderRegistry: 確定性編碼器注冊(cè)表 def __init__(self): self._coders: dict[str, BaseCoder] {} self._register(ModelCoder()) self._register(RestCoder()) def _register(self, coder: BaseCoder): self._coders[coder.name] coder def get(self, name: str) - BaseCoder: if name not in self._coders: raise KeyError(fUnknown coder: {name}) return self._coders[name] def available_coders(self) - str: return , .join(self._coders.keys())注冊(cè)表在這套架構(gòu)里的價(jià)值很清楚如果要新增一種代碼生成能力只需要新增一個(gè) BaseCoder 子類(lèi)并注冊(cè)LLM 控制層不需要任何改動(dòng)。4.3 編寫(xiě) LLM 控制層LLM 控制層是整個(gè)系統(tǒng)的關(guān)鍵。它的任務(wù)是把自然語(yǔ)言需求轉(zhuǎn)換為 JSON 計(jì)劃。為了讓輸出穩(wěn)定提示詞中必須明確 JSON 結(jié)構(gòu)并限制可選生成器。以下是一個(gè)簡(jiǎn)化版本# 文件路徑llm/prompts.py SYSTEM_PROMPT 你是一個(gè)代碼生成計(jì)劃器。你不直接寫(xiě)代碼而是根據(jù)用戶(hù)需求輸出一個(gè) JSON 計(jì)劃。 計(jì)劃中每個(gè)任務(wù)包含 generator 和 params 兩個(gè)字段。 可選生成器model_generator、rest_controller_generator model_generator 參數(shù) - entity: 類(lèi)名 - fields: 字段數(shù)組每個(gè)元素包含 name 和 type rest_controller_generator 參數(shù) - entity: 類(lèi)名 - base_path: 可選REST 基礎(chǔ)路徑 只輸出 JSON不要輸出任何解釋。 .strip()然后是實(shí)現(xiàn)控制器的代碼。這里要求 LLM 返回嚴(yán)格的 JSON并用response_format{type: json_object}保底。# 文件路徑llm/controller.py import json from openai import OpenAI from llm.prompts import SYSTEM_PROMPT class LLMController: LLM 控制層把自然語(yǔ)言需求轉(zhuǎn)換為代碼生成計(jì)劃 def __init__(self, base_url: str, api_key: str, model: str): self.client OpenAI(base_urlbase_url, api_keyapi_key) self.model model def plan(self, user_requirement: str) - dict: response self.client.chat.completions.create( modelself.model, temperature0, response_format{type: json_object}, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_requirement}, ], ) content response.choices[0].message.content return json.loads(content)這里有一個(gè)非常重要的設(shè)置temperature0。雖然 deterministic coder 已經(jīng)保證了代碼生成階段可復(fù)現(xiàn)但 LLM 規(guī)劃階段的不穩(wěn)定性仍然會(huì)傳導(dǎo)到最終產(chǎn)物。把 temperature 設(shè)為 0可以最大程度減少規(guī)劃階段隨機(jī)性。4.4 主流程串聯(lián)現(xiàn)在把控制器、注冊(cè)表、生成引擎串起來(lái)。主流程如下接收用戶(hù)需求LLM 輸出計(jì)劃 JSON遍歷計(jì)劃中的任務(wù)從注冊(cè)表取出對(duì)應(yīng)生成器調(diào)用生成器得到代碼寫(xiě)入 output 目錄。# 文件路徑main.py import json import os import sys from coder.registry import CoderRegistry from llm.controller import LLMController def run(requirement: str, output_dir: str output): controller LLMController( base_urlhttp://localhost:8000/v1, api_keyEMPTY, modelyour-model-name, ) registry CoderRegistry() plan controller.plan(requirement) print(生成的計(jì)劃) print(json.dumps(plan, ensure_asciiFalse, indent2)) os.makedirs(output_dir, exist_okTrue) for task in plan.get(tasks, []): generator_name task[generator] params task[params] coder registry.get(generator_name) code coder.generate(params) entity params.get(entity, Generated) file_name f{entity.lower()}_{generator_name.replace(_generator, )}.py file_path os.path.join(output_dir, file_name) with open(file_path, w, encodingutf-8) as f: f.write(code) print(f已生成文件{file_path}) if __name__ __main__: requirement sys.argv[1] if len(sys.argv) 1 else 創(chuàng)建一個(gè) User 數(shù)據(jù)類(lèi)包含 id、name、email 字段并生成對(duì)應(yīng)的 REST 接口 run(requirement)如果 LLM 返回的計(jì)劃如下{ tasks: [ { generator: model_generator, params: { entity: User, fields: [ {name: id, type: int}, {name: name, type: str}, {name: email, type: str} ] } }, { generator: rest_controller_generator, params: { entity: User, base_path: /users } } ] }那么 output 目錄下會(huì)生成兩個(gè)文件user_model.pyfrom dataclasses import dataclass dataclass class User: id: int name: str email: struser_rest.py# User REST Controller class UserController: base_path /users def list(self): raise NotImplementedError def get(self, id): raise NotImplementedError def create(self, data): raise NotImplementedError def update(self, id, data): raise NotImplementedError def delete(self, id): raise NotImplementedError這就是一個(gè)完整的 Sif 1.0 最小流程。LLM 沒(méi)有直接生成這些代碼它只負(fù)責(zé)把“創(chuàng)建一個(gè) User 數(shù)據(jù)類(lèi)包含 id、name、email 字段并生成對(duì)應(yīng)的 REST 接口”這句話(huà)拆解成結(jié)構(gòu)化計(jì)劃。真正產(chǎn)出代碼的是確定性生成器。4.5 運(yùn)行與驗(yàn)證結(jié)果運(yùn)行命令很簡(jiǎn)單python main.py 創(chuàng)建一個(gè) Product 數(shù)據(jù)類(lèi)包含 id、name、price 字段并生成對(duì)應(yīng)的 REST 接口預(yù)期輸出類(lèi)似生成的計(jì)劃 { tasks: [ { generator: model_generator, params: { entity: Product, fields: [ {name: id, type: int}, {name: name, type: str}, {name: price, type: float} ] } }, { generator: rest_controller_generator, params: { entity: Product, base_path: /products } } ] } 已生成文件output/product_model.py 已生成文件output/product_rest.py由于生成器是確定性的多次運(yùn)行相同計(jì)劃得到的結(jié)果完全一樣。這比直接讓 LLM 生成代碼更接近工程化要求。5. 常見(jiàn)問(wèn)題與排查思路這一節(jié)匯總我在實(shí)際搭建類(lèi)似系統(tǒng)時(shí)遇到過(guò)的高頻問(wèn)題按問(wèn)題現(xiàn)象、原因、解決思路整理成一張速查表。問(wèn)題現(xiàn)象常見(jiàn)原因解決思路LLM 返回的不是合法 JSON提示詞約束不足或模型不支持 JSON 模式在提示詞中給出完整 JSON 示例優(yōu)先使用 response_format增加異常重試邏輯LLM 輸出了未注冊(cè)的生成器名可選生成器列表沒(méi)有寫(xiě)進(jìn)提示詞把注冊(cè)表的 available_coders() 動(dòng)態(tài)拼進(jìn) system prompt生成代碼出現(xiàn)空字段LLM 計(jì)劃中 fields 數(shù)組為空在計(jì)劃校驗(yàn)階段增加參數(shù)非空校驗(yàn)并讓 LLM 重新生成參數(shù)類(lèi)型與生成器預(yù)期不一致LLM 沒(méi)有嚴(yán)格遵守字段類(lèi)型約束使用 Pydantic 定義計(jì)劃結(jié)構(gòu)解析失敗時(shí)返回錯(cuò)誤信息給 LLM 重新規(guī)劃連續(xù)多次輸出結(jié)果不一致LLM 規(guī)劃溫度過(guò)高顯式設(shè)置 temperature0必要時(shí)對(duì) LLM 輸出做歸一化排序新增生成器后仍然報(bào) Unknown coder注冊(cè)表未注冊(cè)或文件未導(dǎo)入檢查注冊(cè)表構(gòu)造器里是否創(chuàng)建了對(duì)應(yīng)實(shí)例生成代碼存在語(yǔ)法錯(cuò)誤模板拼接邏輯有邊界問(wèn)題增加一次性 python -m py_compile 校驗(yàn)并打印出錯(cuò)文件如果你希望更穩(wěn)健可以在 LLM 控制層外面包一層校驗(yàn)函數(shù)。下面給出一個(gè)用 Pydantic 做計(jì)劃校驗(yàn)的示例。# 文件路徑validator.py from typing import List, Optional from pydantic import BaseModel, Field class FieldSpec(BaseModel): name: str type: str class TaskSpec(BaseModel): generator: str params: dict class PlanSpec(BaseModel): tasks: List[TaskSpec] def validate_plan(raw_plan: dict) - PlanSpec: 校驗(yàn) LLM 輸出的計(jì)劃不合法時(shí)拋出異常 return PlanSpec.model_validate(raw_plan)然后修改 main.py增加一步 validate_planplan controller.plan(requirement) validated_plan validate_plan(plan)這樣做的好處是字段缺失、類(lèi)型錯(cuò)誤會(huì)直接拋出異常而不會(huì)等到生成代碼時(shí)才暴露。另一個(gè)常見(jiàn)坑是LLM 容易把 params 里不需要的字段也帶出來(lái)。比如 model_generator 并不需要 base_path但 LLM 可能順手加上。生成器內(nèi)部應(yīng)該忽略多余字段而不是報(bào)錯(cuò)。上面兩個(gè)生成器實(shí)現(xiàn)已經(jīng)做到了這一點(diǎn)因?yàn)樗鼈冎粡?params 取出自己關(guān)心的字段。6. 最佳實(shí)踐與工程建議如果只是做一個(gè) Demo上面 4 個(gè)步驟已經(jīng)完全夠用。但如果你想把“LLM 控制 deterministic coder”這套模式落地到真實(shí)項(xiàng)目下面這些工程建議非常值得重視。6.1 先定義好“代碼生成協(xié)議”LLM 和 deterministic coder 之間的協(xié)議是整個(gè)系統(tǒng)最核心的約束。協(xié)議一旦定義清楚LLM 的規(guī)劃自由度、coder 的參數(shù)校驗(yàn)、驗(yàn)證層的回歸測(cè)試就都有據(jù)可依。建議在項(xiàng)目里維護(hù)一份協(xié)議文檔至少包含生成器名稱(chēng)列表每個(gè)生成器的必填參數(shù)和可選參數(shù)參數(shù)類(lèi)型輸出文件命名規(guī)則已知限制。這套協(xié)議就相當(dāng)于 LLM 的“API 文檔”。在提示詞里注入精簡(jiǎn)版在驗(yàn)證層實(shí)現(xiàn)參數(shù)校驗(yàn)在注冊(cè)表實(shí)現(xiàn)生成器查找。6.2 把 LLM 輸出限制在“小決策”范圍內(nèi)Sif 1.0 的核心不是讓 LLM 做更多而是讓 LLM 做更少但更準(zhǔn)確。實(shí)際設(shè)計(jì)中可以讓 LLM 決策以下內(nèi)容選擇哪個(gè)生成器給生成器填充哪些參數(shù)生成結(jié)果是否滿(mǎn)足原始需求哪些任務(wù)可以并行生成出現(xiàn)驗(yàn)證錯(cuò)誤時(shí)如何調(diào)整參數(shù)。不要讓它決策代碼縮進(jìn)風(fēng)格、注釋格式、導(dǎo)入順序、框架選型——這些都應(yīng)該由 deterministic coder 內(nèi)部邏輯固定。這樣做的收益是模型能力不會(huì)成為代碼質(zhì)量的上限。今天用開(kāi)源模型明天換商業(yè)模型只要它還能輸出結(jié)構(gòu)合理的計(jì)劃 JSON整體系統(tǒng)質(zhì)量就保持穩(wěn)定。6.3 結(jié)果緩存與回歸測(cè)試確定性生成器帶來(lái)的直接好處就是可以緩存。如果 LLM 輸出了相同計(jì)劃理論上不需要重新生成代碼?？梢园从?jì)劃的哈希值做結(jié)果緩存import hashlib import json def plan_hash(plan: dict) - str: raw json.dumps(plan, sort_keysTrue, ensure_asciiFalse) return hashlib.sha256(raw.encode(utf-8)).hexdigest()同時(shí)每次生成的結(jié)果都應(yīng)該納入回歸測(cè)試。最簡(jiǎn)單的做法是在生成代碼后執(zhí)行編譯檢查或測(cè)試斷言更進(jìn)階的做法是建立 golden file基線(xiàn)文件機(jī)制比較本次生成結(jié)果與基線(xiàn)文件的差異。只要不是有意修改代碼生成器任何 diff 都應(yīng)該被當(dāng)成異常處理。6.4 日志與審計(jì)生產(chǎn)環(huán)境中LLM 的每一次規(guī)劃都應(yīng)當(dāng)記錄完整上下文包括用戶(hù)原始需求LLM 輸出的計(jì)劃 JSON計(jì)劃哈希使用的模型名稱(chēng)與版本生成時(shí)間生成結(jié)果是否通過(guò)校驗(yàn)。這些日志既用于問(wèn)題追蹤也用于后續(xù)統(tǒng)計(jì)哪些生成器使用頻率高、哪些需求 LLM 經(jīng)常規(guī)劃失敗。它們會(huì)反過(guò)來(lái)幫助你改進(jìn)提示詞和協(xié)議。6.5 安全邊界雖然本文討論的是代碼生成框架但涉及 LLM 調(diào)用時(shí)仍然要提安全邊界。對(duì)于企業(yè)內(nèi)部工具建議做到LLM 請(qǐng)求只發(fā)送必要數(shù)據(jù)避免把完整數(shù)據(jù)庫(kù)結(jié)構(gòu)、生產(chǎn)配置、敏感代碼注入提示詞對(duì) LLM 輸出做嚴(yán)格 JSON 解析不直接執(zhí)行任何模型返回的腳本生成器代碼不拼接 shell 命令避免注入風(fēng)險(xiǎn)API Key 使用環(huán)境變量或密鑰管理服務(wù)管理不寫(xiě)入代碼倉(cāng)庫(kù)如果 LLM 規(guī)劃出現(xiàn)超時(shí)或異常應(yīng)有降級(jí)策略而不是直接失敗。6.6 漸進(jìn)式替換 LLM 模型Sif 1.0 這類(lèi)架構(gòu)非常適合做模型灰度替換。同一個(gè)用戶(hù)需求分別用舊模型和新模型生成計(jì)劃然后把計(jì)劃交給同一個(gè) deterministic coder對(duì)比最終產(chǎn)物差異。由于確定性 coder 消除了代碼生成階段的隨機(jī)性最終產(chǎn)物差異可以精確歸因到 LLM 規(guī)劃能力本身。這對(duì)評(píng)估模型效果非常有幫助。甚至可以批量構(gòu)造測(cè)試集統(tǒng)計(jì)新舊模型在“計(jì)劃成功率”“參數(shù)正確率”“無(wú)效生成器使用概率”等指標(biāo)上的差異形成結(jié)構(gòu)化的模型評(píng)測(cè)報(bào)告。7. 從 Demo 到生產(chǎn)的關(guān)鍵一步很多同學(xué)看到這里可能會(huì)有一個(gè)疑問(wèn)上面示例里的 deterministic coder 太簡(jiǎn)單了真正的項(xiàng)目里代碼生成哪有這么容易這就是 Sif 1.0 這類(lèi)架構(gòu)最值得深入的地方。它的核心貢獻(xiàn)不是某個(gè)具體的代碼生成器而是把“自然語(yǔ)言需求 → 最終代碼”這個(gè)原本無(wú)法拆解的黑盒過(guò)程拆成了兩層LLM 負(fù)責(zé)理解與規(guī)劃輸出可校驗(yàn)的中間表示確定性系統(tǒng)負(fù)責(zé)生成與執(zhí)行輸出可復(fù)現(xiàn)的最終產(chǎn)物。只要這個(gè)拆解成立后面的擴(kuò)展就是水到渠成的事。你可以把 model_coder 換成更復(fù)雜的模板引擎把 rest_coder 換成帶強(qiáng)類(lèi)型約束的代碼生成器也可以通過(guò)集成編譯器和測(cè)試框架讓驗(yàn)證層更自動(dòng)化。下一步可以繼續(xù)研究的方向包括用形式化 schema 定義生成器協(xié)議并自動(dòng)生成校驗(yàn)器引入多輪反饋?zhàn)?LLM 根據(jù)編譯錯(cuò)誤修正計(jì)劃構(gòu)建“計(jì)劃日志”數(shù)據(jù)集用它微調(diào)一個(gè)更擅長(zhǎng)規(guī)劃的小模型把確定性編碼器擴(kuò)展到數(shù)據(jù)庫(kù)遷移、API 文檔生成、配置文件生成等場(chǎng)景。如果這篇文章對(duì)你有幫助建議先照著上面的流程搭一個(gè)最小版本把“模型規(guī)劃 → 生成器執(zhí)行 → 代碼輸出”三個(gè)環(huán)節(jié)跑通。跑通之后你一定會(huì)更清楚自己的項(xiàng)目里哪些部分應(yīng)該交給 LLM哪些部分應(yīng)該回歸確定性系統(tǒng)。 Sif 1.0：用LLM控制確定性編碼器，讓AI代碼生成可復(fù)現(xiàn)
先聊一個(gè)現(xiàn)象現(xiàn)在很多同學(xué)使用 LLM 生成代碼已經(jīng)習(xí)慣了“描述需求 → 拿到大段代碼 → 復(fù)制 → 調(diào)試 → 再讓模型修復(fù)”的循環(huán)。這種開(kāi)發(fā)方式有一個(gè)很形象的說(shuō)法叫 vibe coding也就是只憑“感覺(jué)”讓大模型把代碼寫(xiě)出來(lái)自己負(fù)責(zé)驗(yàn)收和兜底。它的效率確實(shí)很高但真正的團(tuán)隊(duì)項(xiàng)目或者正式環(huán)境里不驗(yàn)證生成結(jié)果、不固定生成過(guò)程、讓模型反復(fù)輸出風(fēng)格不穩(wěn)定的代碼很容易埋下不可維護(hù)的隱患。本文要聊的 Sif 1.0正是這種背景下出現(xiàn)的一個(gè)很有意思的嘗試。它的核心不是“讓 LLM 生成代碼”而是讓 LLM 去控制一個(gè) deterministic coder確定性編碼器。也就是說(shuō)把大模型的角色從“手寫(xiě)代碼的工具人”變成“下指令、做決策、驗(yàn)收產(chǎn)物的指揮官”同時(shí)把真正產(chǎn)生代碼的部分交給可預(yù)測(cè)、可重復(fù)、可回歸的確定性組件來(lái)執(zhí)行。這篇文章會(huì)圍繞 Sif 1.0 的設(shè)計(jì)思路展開(kāi)以下內(nèi)容什么是 deterministic coder它和普通 AI 生成代碼有什么區(qū)別Sif 1.0 的整體架構(gòu)是怎樣的LLM 在其中扮演什么角色如何用 Python 親手搭建一個(gè)“LLM 控制確定性編碼器”的最小示例實(shí)際使用中常見(jiàn)的問(wèn)題、排查思路與工程化建議。無(wú)論你是對(duì) LLM Agent 感興趣的開(kāi)發(fā)者還是正在做 AI 編程工具、內(nèi)部代碼生成平臺(tái)這篇文章都能提供一個(gè)比較完整的參考。1. 背景與核心概念1.1 從 vibe coding 到 LLM AgentVibe coding 這個(gè)詞這幾年很流行它的核心特征是開(kāi)發(fā)者不再逐行編寫(xiě)代碼而是用自然語(yǔ)言描述意圖把實(shí)現(xiàn)細(xì)節(jié)交給 LLM 完成。這種方式在快速原型、腳本編寫(xiě)、臨時(shí)工具開(kāi)發(fā)上效率極高特別適合驗(yàn)證想法。但它的缺點(diǎn)也很明顯輸出不穩(wěn)定同樣的提示詞多次生成結(jié)果可能不同質(zhì)量不可控模型可能一本正經(jīng)地生成有邏輯漏洞的代碼回歸困難項(xiàng)目后期修復(fù)一個(gè) bug可能把另一個(gè)模塊改壞審計(jì)困難無(wú)法追溯到某段代碼的生成依據(jù)和驗(yàn)證過(guò)程。正因?yàn)檫@些問(wèn)題很多團(tuán)隊(duì)開(kāi)始把目光從“讓 LLM 直接寫(xiě)代碼”轉(zhuǎn)向“讓 LLM 編排代碼生成流程”。LLM 的任務(wù)不再是吐出大段代碼而是理解需求、拆分任務(wù)、選擇合適的確定性組件、傳遞參數(shù)、檢查輸出結(jié)果。這個(gè)方向逐漸演變成 LLM Agent 的一個(gè)重要分支。1.2 deterministic coder 是什么Deterministic coder即確定性編碼器指的是一類(lèi)“在相同輸入條件下輸出完全可復(fù)現(xiàn)”的代碼生成組件。它的特點(diǎn)包括有明確的輸入輸出契約不依賴(lài)概率采樣生成結(jié)果可回歸驗(yàn)證執(zhí)行過(guò)程可以通過(guò)日志完整追蹤通?；谀０?、DSL、代碼生成器或編譯機(jī)制實(shí)現(xiàn)。舉個(gè)最簡(jiǎn)單的例子一個(gè)根據(jù)數(shù)據(jù)庫(kù)表結(jié)構(gòu)生成 Mapper 代碼的工具輸入是表結(jié)構(gòu) JSON輸出是完整的 Java Mapper 文件。只要輸入不變輸出永遠(yuǎn)相同。這就是典型的 deterministic coder。1.3 Sif 1.0 的定位Sif 1.0 的核心思路是用 LLM 來(lái)控制一個(gè)或者多個(gè) deterministic coder組成一套“LLM 做決策、確定性組件做執(zhí)行”的代碼生成流水線(xiàn)。如果把它和傳統(tǒng) vibe coding 做對(duì)比會(huì)更清晰維度傳統(tǒng) vibe codingSif 1.0 思路LLM 角色直接生成最終代碼輸出任務(wù)計(jì)劃、參數(shù)和校驗(yàn)結(jié)果代碼來(lái)源LLM 概率采樣確定性編碼器按計(jì)劃生成可重復(fù)性不穩(wěn)定同一計(jì)劃產(chǎn)出相同代碼質(zhì)量保證靠人工審查計(jì)劃校驗(yàn) 生成結(jié)果校驗(yàn) 人工抽查適用場(chǎng)景原型驗(yàn)證、腳本工具工程化代碼生成、遺留系統(tǒng)改造Sif 1.0 不把 LLM 當(dāng)成“萬(wàn)能的代碼生成器”而是把 LLM 放在一個(gè)更合理的位置理解模糊業(yè)務(wù)需求轉(zhuǎn)換成結(jié)構(gòu)化的代碼生成指令再把指令交給專(zhuān)門(mén)負(fù)責(zé)某一類(lèi)代碼產(chǎn)物的確定性生成器。這種設(shè)計(jì)帶來(lái)的價(jià)值很直接代碼風(fēng)格一致生成過(guò)程可審計(jì)回歸測(cè)試可以自動(dòng)化不依賴(lài)某一個(gè)大模型的編碼能力降低模型替換成本。2. Sif 1.0 的架構(gòu)與設(shè)計(jì)思路要理解 Sif 1.0需要先拆解它的架構(gòu)分層。它并不是一個(gè)單一的庫(kù)或模型而是一套“控制框架”核心組件包括三個(gè)部分LLM 控制層、確定性編碼引擎、驗(yàn)證與反饋層。2.1 LLM 控制層LLM 控制層是系統(tǒng)的“大腦”。它負(fù)責(zé)接收用戶(hù)自然語(yǔ)言需求分析需求拆解為多個(gè)子任務(wù)從確定性編碼器注冊(cè)表中選擇合適的生成器為每個(gè)生成器生成結(jié)構(gòu)化參數(shù)對(duì)生成結(jié)果進(jìn)行初步評(píng)估根據(jù)驗(yàn)證結(jié)果決定是否重新調(diào)整參數(shù)。這一層的關(guān)鍵不是讓 LLM 直接寫(xiě)代碼而是讓 LLM 輸出結(jié)構(gòu)清晰的中間計(jì)劃。例如用戶(hù)說(shuō)“幫我生成一個(gè)用戶(hù)管理的 REST 接口”LLM 并不需要直接輸出 Controller、Service、Mapper 的代碼而是應(yīng)該輸出類(lèi)似這樣的計(jì)劃{ tasks: [ { generator: rest_controller_generator, params: { entity: User, fields: [id, name, email, created_at], operations: [list, get, create, update, delete] } }, { generator: mybatis_mapper_generator, params: { entity: User, table: t_user, primary_key: id } } ] }這個(gè) JSON 是可控的。LLM 只負(fù)責(zé)理解需求并填充結(jié)構(gòu)化參數(shù)不負(fù)責(zé)生成大段代碼。這樣一來(lái)LLM 的“犯錯(cuò)空間”被大幅壓縮。2.2 確定性編碼引擎編碼引擎由一組 deterministic coder 組成。每個(gè) coder 都只負(fù)責(zé)一種特定類(lèi)型的代碼產(chǎn)物并且是純函數(shù)式的輸入?yún)?shù) → 輸出代碼。常見(jiàn)的 deterministic coder 類(lèi)型包括REST 接口生成器輸入實(shí)體定義輸出 Controller數(shù)據(jù)訪問(wèn)層生成器輸入表結(jié)構(gòu)輸出 Mapper/RepositoryDTO/VO 生成器輸入字段定義輸出數(shù)據(jù)類(lèi)配置類(lèi)生成器輸入配置項(xiàng)輸出 YAML/properties數(shù)據(jù)庫(kù)遷移腳本生成器輸入變更描述輸出版本化 SQL。這些生成器通常使用模板引擎、代碼模型或 DSL 實(shí)現(xiàn)。它們必須是確定性的——這不僅是工程需求也是 Sif 1.0 這個(gè)名字想表達(dá)的核心價(jià)值LLM 負(fù)責(zé)“品味”確定性引擎負(fù)責(zé)“穩(wěn)定”。2.3 驗(yàn)證與反饋層驗(yàn)證層是最容易被忽略、但實(shí)際項(xiàng)目中最重要的部分。Sif 1.0 中LLM 輸出計(jì)劃后、確定性組件生成代碼后都會(huì)經(jīng)過(guò)驗(yàn)證環(huán)節(jié)計(jì)劃校驗(yàn)參數(shù)缺失、類(lèi)型錯(cuò)誤、字段不存在生成結(jié)果校驗(yàn)語(yǔ)法檢查、編譯檢查、單元測(cè)試回歸校驗(yàn)與歷史生成結(jié)果對(duì)比防止意外變更人工評(píng)審最終由開(kāi)發(fā)人員確認(rèn)。驗(yàn)證失敗時(shí)反饋信息會(huì)回流到 LLM 控制層由 LLM 修正計(jì)劃。這就是一個(gè)完整的閉環(huán)。這樣設(shè)計(jì)的另一個(gè)好處是模型可以被替換。今天用 GPT-4明天換成其他模型只要它還能輸出符合約定的計(jì)劃 JSON整個(gè)系統(tǒng)就能繼續(xù)工作。確定性編碼引擎完全不受模型升級(jí)影響。3. 環(huán)境準(zhǔn)備與版本說(shuō)明在動(dòng)手寫(xiě)示例之前先說(shuō)明運(yùn)行環(huán)境。根據(jù)多個(gè)實(shí)際項(xiàng)目經(jīng)驗(yàn)Sif 這類(lèi)“LLM 確定性編碼器”的組合并不依賴(lài)特定云服務(wù)只要本地能調(diào)用 LLM API 即可。本文示例的開(kāi)發(fā)環(huán)境如下操作系統(tǒng)Windows 10 / macOS / Linux 均可Python3.10依賴(lài)庫(kù)openai、pydantic、jinja2、pyyamlLLM 接口兼容 OpenAI API 格式的服務(wù)或本地部署模型IDEVS Code / PyCharm或直接用命令行。這里需要特別強(qiáng)調(diào)不同項(xiàng)目的依賴(lài)版本差異較大如果你本地的 openai 庫(kù)版本較新部分 API 參數(shù)可能發(fā)生變化。本文示例代碼以“配置 base_url api_key”的方式調(diào)用兼容大部分 OpenAI 兼容接口。如果你沒(méi)有可直接使用的 LLM API也可以先用一個(gè)小型本地模型替代只要它支持 JSON 格式輸出。下面所有示例都把 LLM 輸出嚴(yán)格約束為 JSON方便后續(xù)解析。建議創(chuàng)建一個(gè)獨(dú)立的虛擬環(huán)境python -m venv sif-demo source sif-demo/bin/activate # Windows 使用 sif-demo\Scripts\activate pip install openai pydantic jinja2 pyyaml項(xiàng)目結(jié)構(gòu)建議如下sif-demo/ ├── main.py # 入口組合控制層和生成引擎 ├── coder/ │ ├── __init__.py │ ├── registry.py # 確定性編碼器注冊(cè)表 │ ├── rest_coder.py # REST 接口生成器 │ └── model_coder.py # 數(shù)據(jù)類(lèi)生成器 ├── llm/ │ ├── __init__.py │ ├── controller.py # LLM 控制層 │ └── prompts.py # 提示詞模板 ├── plans/ │ └── plan.json # LLM 輸出的中間計(jì)劃 └── output/ # 生成的代碼輸出目錄不用完全照搬這個(gè)結(jié)構(gòu)但建議保持“控制器、注冊(cè)表、生成器”三部分分離。4. 實(shí)戰(zhàn)讓 LLM 驅(qū)動(dòng)確定性代碼生成器下面我們動(dòng)手實(shí)現(xiàn)一個(gè)最小可運(yùn)行的 Sif 1.0 流程。為了讓例子更直觀我會(huì)讓 LLM 根據(jù)一段自然語(yǔ)言需求輸出一個(gè) JSON 計(jì)劃然后由兩個(gè) deterministic coder 分別生成 Python 數(shù)據(jù)類(lèi)和 REST 接口骨架。4.1 定義確定性編碼器先寫(xiě)一個(gè)基礎(chǔ)的生成器抽象。這里使用一個(gè)很簡(jiǎn)單的接口每個(gè)生成器內(nèi)部實(shí)現(xiàn)generate(params) - str方法返回代碼字符串。# 文件路徑coder/base.py from abc import ABC, abstractmethod from typing import Any, Dict class BaseCoder(ABC): 確定性編碼器抽象基類(lèi) name: str base abstractmethod def generate(self, params: Dict[str, Any]) - str: 根據(jù)參數(shù)生成代碼必須保證相同參數(shù)產(chǎn)生相同輸出 pass接下來(lái)實(shí)現(xiàn)一個(gè)數(shù)據(jù)類(lèi)生成器。它的輸入是實(shí)體名稱(chēng)和字段列表輸出是 Python dataclass。# 文件路徑coder/model_coder.py from typing import Any, Dict, List from coder.base import BaseCoder class ModelCoder(BaseCoder): 生成 Python dataclass 的確定性編碼器 name model_generator def generate(self, params: Dict[str, Any]) - str: entity: str params[entity] fields: List[Dict[str, str]] params[fields] lines [from dataclasses import dataclass, ] lines.append(fdataclass) lines.append(fclass {entity}:) if not fields: lines.append( pass) else: for field in fields: fname field[name] ftype field[type] lines.append(f {fname}: {ftype}) return \n.join(lines) \n再實(shí)現(xiàn)一個(gè) REST 接口生成器把實(shí)體名轉(zhuǎn)換成 Controller 骨架。這里不依賴(lài)任何 Web 框架只是生成一個(gè)類(lèi)體現(xiàn)確定性代碼生成的過(guò)程。# 文件路徑coder/rest_coder.py from typing import Any, Dict, List from coder.base import BaseCoder class RestCoder(BaseCoder): 生成 REST 接口骨架的確定性編碼器 name rest_controller_generator def generate(self, params: Dict[str, Any]) - str: entity: str params[entity] base_path: str params.get(base_path, f/{entity.lower()}) lines [f# {entity} REST Controller, ] lines.append(fclass {entity}Controller:) lines.append(f base_path {base_path!r}) lines.append() lines.append( def list(self):) lines.append( raise NotImplementedError) lines.append() lines.append( def get(self, id):) lines.append( raise NotImplementedError) lines.append() lines.append( def create(self, data):) lines.append( raise NotImplementedError) lines.append() lines.append( def update(self, id, data):) lines.append( raise NotImplementedError) lines.append() lines.append( def delete(self, id):) lines.append( raise NotImplementedError) return \n.join(lines) \n這兩個(gè)生成器都是完全確定性的輸入相同參數(shù)輸出永遠(yuǎn)一致。它們甚至不依賴(lài) LLM。4.2 實(shí)現(xiàn)注冊(cè)表接下里把生成器放進(jìn)注冊(cè)表。注冊(cè)表的作用是讓 LLM 控制層按照名字查找生成器而不需要感知具體類(lèi)。# 文件路徑coder/registry.py from coder.base import BaseCoder from coder.model_coder import ModelCoder from coder.rest_coder import RestCoder class CoderRegistry: 確定性編碼器注冊(cè)表 def __init__(self): self._coders: dict[str, BaseCoder] {} self._register(ModelCoder()) self._register(RestCoder()) def _register(self, coder: BaseCoder): self._coders[coder.name] coder def get(self, name: str) - BaseCoder: if name not in self._coders: raise KeyError(fUnknown coder: {name}) return self._coders[name] def available_coders(self) - str: return , .join(self._coders.keys())注冊(cè)表在這套架構(gòu)里的價(jià)值很清楚如果要新增一種代碼生成能力只需要新增一個(gè) BaseCoder 子類(lèi)并注冊(cè)LLM 控制層不需要任何改動(dòng)。4.3 編寫(xiě) LLM 控制層LLM 控制層是整個(gè)系統(tǒng)的關(guān)鍵。它的任務(wù)是把自然語(yǔ)言需求轉(zhuǎn)換為 JSON 計(jì)劃。為了讓輸出穩(wěn)定提示詞中必須明確 JSON 結(jié)構(gòu)并限制可選生成器。以下是一個(gè)簡(jiǎn)化版本# 文件路徑llm/prompts.py SYSTEM_PROMPT 你是一個(gè)代碼生成計(jì)劃器。你不直接寫(xiě)代碼而是根據(jù)用戶(hù)需求輸出一個(gè) JSON 計(jì)劃。 計(jì)劃中每個(gè)任務(wù)包含 generator 和 params 兩個(gè)字段。 可選生成器model_generator、rest_controller_generator model_generator 參數(shù) - entity: 類(lèi)名 - fields: 字段數(shù)組每個(gè)元素包含 name 和 type rest_controller_generator 參數(shù) - entity: 類(lèi)名 - base_path: 可選REST 基礎(chǔ)路徑 只輸出 JSON不要輸出任何解釋。 .strip()然后是實(shí)現(xiàn)控制器的代碼。這里要求 LLM 返回嚴(yán)格的 JSON并用response_format{type: json_object}保底。# 文件路徑llm/controller.py import json from openai import OpenAI from llm.prompts import SYSTEM_PROMPT class LLMController: LLM 控制層把自然語(yǔ)言需求轉(zhuǎn)換為代碼生成計(jì)劃 def __init__(self, base_url: str, api_key: str, model: str): self.client OpenAI(base_urlbase_url, api_keyapi_key) self.model model def plan(self, user_requirement: str) - dict: response self.client.chat.completions.create( modelself.model, temperature0, response_format{type: json_object}, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_requirement}, ], ) content response.choices[0].message.content return json.loads(content)這里有一個(gè)非常重要的設(shè)置temperature0。雖然 deterministic coder 已經(jīng)保證了代碼生成階段可復(fù)現(xiàn)但 LLM 規(guī)劃階段的不穩(wěn)定性仍然會(huì)傳導(dǎo)到最終產(chǎn)物。把 temperature 設(shè)為 0可以最大程度減少規(guī)劃階段隨機(jī)性。4.4 主流程串聯(lián)現(xiàn)在把控制器、注冊(cè)表、生成引擎串起來(lái)。主流程如下接收用戶(hù)需求LLM 輸出計(jì)劃 JSON遍歷計(jì)劃中的任務(wù)從注冊(cè)表取出對(duì)應(yīng)生成器調(diào)用生成器得到代碼寫(xiě)入 output 目錄。# 文件路徑main.py import json import os import sys from coder.registry import CoderRegistry from llm.controller import LLMController def run(requirement: str, output_dir: str output): controller LLMController( base_urlhttp://localhost:8000/v1, api_keyEMPTY, modelyour-model-name, ) registry CoderRegistry() plan controller.plan(requirement) print(生成的計(jì)劃) print(json.dumps(plan, ensure_asciiFalse, indent2)) os.makedirs(output_dir, exist_okTrue) for task in plan.get(tasks, []): generator_name task[generator] params task[params] coder registry.get(generator_name) code coder.generate(params) entity params.get(entity, Generated) file_name f{entity.lower()}_{generator_name.replace(_generator, )}.py file_path os.path.join(output_dir, file_name) with open(file_path, w, encodingutf-8) as f: f.write(code) print(f已生成文件{file_path}) if __name__ __main__: requirement sys.argv[1] if len(sys.argv) 1 else 創(chuàng)建一個(gè) User 數(shù)據(jù)類(lèi)包含 id、name、email 字段并生成對(duì)應(yīng)的 REST 接口 run(requirement)如果 LLM 返回的計(jì)劃如下{ tasks: [ { generator: model_generator, params: { entity: User, fields: [ {name: id, type: int}, {name: name, type: str}, {name: email, type: str} ] } }, { generator: rest_controller_generator, params: { entity: User, base_path: /users } } ] }那么 output 目錄下會(huì)生成兩個(gè)文件user_model.pyfrom dataclasses import dataclass dataclass class User: id: int name: str email: struser_rest.py# User REST Controller class UserController: base_path /users def list(self): raise NotImplementedError def get(self, id): raise NotImplementedError def create(self, data): raise NotImplementedError def update(self, id, data): raise NotImplementedError def delete(self, id): raise NotImplementedError這就是一個(gè)完整的 Sif 1.0 最小流程。LLM 沒(méi)有直接生成這些代碼它只負(fù)責(zé)把“創(chuàng)建一個(gè) User 數(shù)據(jù)類(lèi)包含 id、name、email 字段并生成對(duì)應(yīng)的 REST 接口”這句話(huà)拆解成結(jié)構(gòu)化計(jì)劃。真正產(chǎn)出代碼的是確定性生成器。4.5 運(yùn)行與驗(yàn)證結(jié)果運(yùn)行命令很簡(jiǎn)單python main.py 創(chuàng)建一個(gè) Product 數(shù)據(jù)類(lèi)包含 id、name、price 字段并生成對(duì)應(yīng)的 REST 接口預(yù)期輸出類(lèi)似生成的計(jì)劃 { tasks: [ { generator: model_generator, params: { entity: Product, fields: [ {name: id, type: int}, {name: name, type: str}, {name: price, type: float} ] } }, { generator: rest_controller_generator, params: { entity: Product, base_path: /products } } ] } 已生成文件output/product_model.py 已生成文件output/product_rest.py由于生成器是確定性的多次運(yùn)行相同計(jì)劃得到的結(jié)果完全一樣。這比直接讓 LLM 生成代碼更接近工程化要求。5. 常見(jiàn)問(wèn)題與排查思路這一節(jié)匯總我在實(shí)際搭建類(lèi)似系統(tǒng)時(shí)遇到過(guò)的高頻問(wèn)題按問(wèn)題現(xiàn)象、原因、解決思路整理成一張速查表。問(wèn)題現(xiàn)象常見(jiàn)原因解決思路LLM 返回的不是合法 JSON提示詞約束不足或模型不支持 JSON 模式在提示詞中給出完整 JSON 示例優(yōu)先使用 response_format增加異常重試邏輯LLM 輸出了未注冊(cè)的生成器名可選生成器列表沒(méi)有寫(xiě)進(jìn)提示詞把注冊(cè)表的 available_coders() 動(dòng)態(tài)拼進(jìn) system prompt生成代碼出現(xiàn)空字段LLM 計(jì)劃中 fields 數(shù)組為空在計(jì)劃校驗(yàn)階段增加參數(shù)非空校驗(yàn)并讓 LLM 重新生成參數(shù)類(lèi)型與生成器預(yù)期不一致LLM 沒(méi)有嚴(yán)格遵守字段類(lèi)型約束使用 Pydantic 定義計(jì)劃結(jié)構(gòu)解析失敗時(shí)返回錯(cuò)誤信息給 LLM 重新規(guī)劃連續(xù)多次輸出結(jié)果不一致LLM 規(guī)劃溫度過(guò)高顯式設(shè)置 temperature0必要時(shí)對(duì) LLM 輸出做歸一化排序新增生成器后仍然報(bào) Unknown coder注冊(cè)表未注冊(cè)或文件未導(dǎo)入檢查注冊(cè)表構(gòu)造器里是否創(chuàng)建了對(duì)應(yīng)實(shí)例生成代碼存在語(yǔ)法錯(cuò)誤模板拼接邏輯有邊界問(wèn)題增加一次性 python -m py_compile 校驗(yàn)并打印出錯(cuò)文件如果你希望更穩(wěn)健可以在 LLM 控制層外面包一層校驗(yàn)函數(shù)。下面給出一個(gè)用 Pydantic 做計(jì)劃校驗(yàn)的示例。# 文件路徑validator.py from typing import List, Optional from pydantic import BaseModel, Field class FieldSpec(BaseModel): name: str type: str class TaskSpec(BaseModel): generator: str params: dict class PlanSpec(BaseModel): tasks: List[TaskSpec] def validate_plan(raw_plan: dict) - PlanSpec: 校驗(yàn) LLM 輸出的計(jì)劃不合法時(shí)拋出異常 return PlanSpec.model_validate(raw_plan)然后修改 main.py增加一步 validate_planplan controller.plan(requirement) validated_plan validate_plan(plan)這樣做的好處是字段缺失、類(lèi)型錯(cuò)誤會(huì)直接拋出異常而不會(huì)等到生成代碼時(shí)才暴露。另一個(gè)常見(jiàn)坑是LLM 容易把 params 里不需要的字段也帶出來(lái)。比如 model_generator 并不需要 base_path但 LLM 可能順手加上。生成器內(nèi)部應(yīng)該忽略多余字段而不是報(bào)錯(cuò)。上面兩個(gè)生成器實(shí)現(xiàn)已經(jīng)做到了這一點(diǎn)因?yàn)樗鼈冎粡?params 取出自己關(guān)心的字段。6. 最佳實(shí)踐與工程建議如果只是做一個(gè) Demo上面 4 個(gè)步驟已經(jīng)完全夠用。但如果你想把“LLM 控制 deterministic coder”這套模式落地到真實(shí)項(xiàng)目下面這些工程建議非常值得重視。6.1 先定義好“代碼生成協(xié)議”LLM 和 deterministic coder 之間的協(xié)議是整個(gè)系統(tǒng)最核心的約束。協(xié)議一旦定義清楚LLM 的規(guī)劃自由度、coder 的參數(shù)校驗(yàn)、驗(yàn)證層的回歸測(cè)試就都有據(jù)可依。建議在項(xiàng)目里維護(hù)一份協(xié)議文檔至少包含生成器名稱(chēng)列表每個(gè)生成器的必填參數(shù)和可選參數(shù)參數(shù)類(lèi)型輸出文件命名規(guī)則已知限制。這套協(xié)議就相當(dāng)于 LLM 的“API 文檔”。在提示詞里注入精簡(jiǎn)版在驗(yàn)證層實(shí)現(xiàn)參數(shù)校驗(yàn)在注冊(cè)表實(shí)現(xiàn)生成器查找。6.2 把 LLM 輸出限制在“小決策”范圍內(nèi)Sif 1.0 的核心不是讓 LLM 做更多而是讓 LLM 做更少但更準(zhǔn)確。實(shí)際設(shè)計(jì)中可以讓 LLM 決策以下內(nèi)容選擇哪個(gè)生成器給生成器填充哪些參數(shù)生成結(jié)果是否滿(mǎn)足原始需求哪些任務(wù)可以并行生成出現(xiàn)驗(yàn)證錯(cuò)誤時(shí)如何調(diào)整參數(shù)。不要讓它決策代碼縮進(jìn)風(fēng)格、注釋格式、導(dǎo)入順序、框架選型——這些都應(yīng)該由 deterministic coder 內(nèi)部邏輯固定。這樣做的收益是模型能力不會(huì)成為代碼質(zhì)量的上限。今天用開(kāi)源模型明天換商業(yè)模型只要它還能輸出結(jié)構(gòu)合理的計(jì)劃 JSON整體系統(tǒng)質(zhì)量就保持穩(wěn)定。6.3 結(jié)果緩存與回歸測(cè)試確定性生成器帶來(lái)的直接好處就是可以緩存。如果 LLM 輸出了相同計(jì)劃理論上不需要重新生成代碼?？梢园从?jì)劃的哈希值做結(jié)果緩存import hashlib import json def plan_hash(plan: dict) - str: raw json.dumps(plan, sort_keysTrue, ensure_asciiFalse) return hashlib.sha256(raw.encode(utf-8)).hexdigest()同時(shí)每次生成的結(jié)果都應(yīng)該納入回歸測(cè)試。最簡(jiǎn)單的做法是在生成代碼后執(zhí)行編譯檢查或測(cè)試斷言更進(jìn)階的做法是建立 golden file基線(xiàn)文件機(jī)制比較本次生成結(jié)果與基線(xiàn)文件的差異。只要不是有意修改代碼生成器任何 diff 都應(yīng)該被當(dāng)成異常處理。6.4 日志與審計(jì)生產(chǎn)環(huán)境中LLM 的每一次規(guī)劃都應(yīng)當(dāng)記錄完整上下文包括用戶(hù)原始需求LLM 輸出的計(jì)劃 JSON計(jì)劃哈希使用的模型名稱(chēng)與版本生成時(shí)間生成結(jié)果是否通過(guò)校驗(yàn)。這些日志既用于問(wèn)題追蹤也用于后續(xù)統(tǒng)計(jì)哪些生成器使用頻率高、哪些需求 LLM 經(jīng)常規(guī)劃失敗。它們會(huì)反過(guò)來(lái)幫助你改進(jìn)提示詞和協(xié)議。6.5 安全邊界雖然本文討論的是代碼生成框架但涉及 LLM 調(diào)用時(shí)仍然要提安全邊界。對(duì)于企業(yè)內(nèi)部工具建議做到LLM 請(qǐng)求只發(fā)送必要數(shù)據(jù)避免把完整數(shù)據(jù)庫(kù)結(jié)構(gòu)、生產(chǎn)配置、敏感代碼注入提示詞對(duì) LLM 輸出做嚴(yán)格 JSON 解析不直接執(zhí)行任何模型返回的腳本生成器代碼不拼接 shell 命令避免注入風(fēng)險(xiǎn)API Key 使用環(huán)境變量或密鑰管理服務(wù)管理不寫(xiě)入代碼倉(cāng)庫(kù)如果 LLM 規(guī)劃出現(xiàn)超時(shí)或異常應(yīng)有降級(jí)策略而不是直接失敗。6.6 漸進(jìn)式替換 LLM 模型Sif 1.0 這類(lèi)架構(gòu)非常適合做模型灰度替換。同一個(gè)用戶(hù)需求分別用舊模型和新模型生成計(jì)劃然后把計(jì)劃交給同一個(gè) deterministic coder對(duì)比最終產(chǎn)物差異。由于確定性 coder 消除了代碼生成階段的隨機(jī)性最終產(chǎn)物差異可以精確歸因到 LLM 規(guī)劃能力本身。這對(duì)評(píng)估模型效果非常有幫助。甚至可以批量構(gòu)造測(cè)試集統(tǒng)計(jì)新舊模型在“計(jì)劃成功率”“參數(shù)正確率”“無(wú)效生成器使用概率”等指標(biāo)上的差異形成結(jié)構(gòu)化的模型評(píng)測(cè)報(bào)告。7. 從 Demo 到生產(chǎn)的關(guān)鍵一步很多同學(xué)看到這里可能會(huì)有一個(gè)疑問(wèn)上面示例里的 deterministic coder 太簡(jiǎn)單了真正的項(xiàng)目里代碼生成哪有這么容易這就是 Sif 1.0 這類(lèi)架構(gòu)最值得深入的地方。它的核心貢獻(xiàn)不是某個(gè)具體的代碼生成器而是把“自然語(yǔ)言需求 → 最終代碼”這個(gè)原本無(wú)法拆解的黑盒過(guò)程拆成了兩層LLM 負(fù)責(zé)理解與規(guī)劃輸出可校驗(yàn)的中間表示確定性系統(tǒng)負(fù)責(zé)生成與執(zhí)行輸出可復(fù)現(xiàn)的最終產(chǎn)物。只要這個(gè)拆解成立后面的擴(kuò)展就是水到渠成的事。你可以把 model_coder 換成更復(fù)雜的模板引擎把 rest_coder 換成帶強(qiáng)類(lèi)型約束的代碼生成器也可以通過(guò)集成編譯器和測(cè)試框架讓驗(yàn)證層更自動(dòng)化。下一步可以繼續(xù)研究的方向包括用形式化 schema 定義生成器協(xié)議并自動(dòng)生成校驗(yàn)器引入多輪反饋?zhàn)?LLM 根據(jù)編譯錯(cuò)誤修正計(jì)劃構(gòu)建“計(jì)劃日志”數(shù)據(jù)集用它微調(diào)一個(gè)更擅長(zhǎng)規(guī)劃的小模型把確定性編碼器擴(kuò)展到數(shù)據(jù)庫(kù)遷移、API 文檔生成、配置文件生成等場(chǎng)景。如果這篇文章對(duì)你有幫助建議先照著上面的流程搭一個(gè)最小版本把“模型規(guī)劃 → 生成器執(zhí)行 → 代碼輸出”三個(gè)環(huán)節(jié)跑通。跑通之后你一定會(huì)更清楚自己的項(xiàng)目里哪些部分應(yīng)該交給 LLM哪些部分應(yīng)該回歸確定性系統(tǒng)。