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