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