本文由作者 twg2020 创作，使用 AI 辅助润色
首发于：somingbai.com
NLCC：用自然语言编写代码的完整系统
NLCC = Natural Language Code Compiler
专业级自然语言编译器，将自然语言描述编译为可执行代码，并提供完整的可视化开发环境
目录
- 设计哲学
- 核心架构
- 技术规格
- Web可视化界面
- 自动化构建系统
- 实践指南
- 技术演化
设计哲学
核心洞察：代码是Cheap的 + 架构确定性
在AI辅助编程的时代，两个根本性变化决定了新的开发范式：
变化1：成本结构倒置
- 代码生成：便宜（AI几秒生成几百行）
- AI理解成本：昂贵（上下文窗口有限）
- AI修改成本：极高（需要重新理解整个系统）
变化2：AI生成的不确定性
- 同样的需求，AI每次生成的代码可能不同
- AI可能产生微妙的bug，难以预测
- 需要通过架构约束来保证正确性
新的成本函数：
总成本 = AI生成代码的时间（低）
+ 人类review的时间（中）
+ AI修改迭代的时间（高）
+ 系统复杂度导致的AI错误率（极高）
+ 不确定性带来的质量风险（新增）
双重结论：
- 牺牲代码复用 - 换取AI注意力的聚焦
- 架构确定性 - 用确定性对抗不确定性
为什么牺牲代码复用？
传统方式：追求代码复用
场景：统一错误处理
// src/common/error.rs
pub struct Error {
code: i32,
message: String,
context: Option<Box<dyn Any>>,
}
pub fn error_handle(err: &Error); // 超级通用的错误处理
传统优势：
- ✅ 只写一次错误处理逻辑
- ✅ 统一的错误格式
- ✅ 易于维护
AI时代的问题：
让AI写使用Error的代码时：
AI的思维过程：
1. 需要处理错误
2. 用Error结构
3. Error有哪些字段？code、message、context...
4. context是什么类型？Option<Box<dyn Any>>？
5. 需要downcast吗？什么具体类型？
6. 有初始化函数吗？
7. 错误码是多少？
8. 要检查None吗？
...（AI注意力被分散到10个细节上）
AI实际生成（很可能出错）：
fn network_send(&self, data: &str) {
if send_failed {
let mut err = Error {
code: 1000,
message: "send failed".to_string(),
context: None, // ❌ 不知道应该设置什么类型
};
error_handle(&err); // ❌ 类型信息可能丢失
}
}
AI方式：牺牲代码复用
// 不设计通用的Error结构
// src/network/impl.rs
fn network_send(&self, data: &str) {
if send_failed {
// 简单直接，网络模块自己的错误处理
eprintln!("[network] send failed: {}", std::io::Error::last_os_error());
if let Some(callback) = &self.error_callback {
callback("send failed");
}
}
}
// src/storage/impl.rs
fn storage_write(&mut self, data: &str) {
if write_failed {
// 存储模块自己的错误处理（完全不同）
eprintln!("[storage] write failed: {}", std::io::Error::last_os_error());
if self.retry_count < 3 {
self.retry_count += 1;
self.storage_write(data); // 自己的重试逻辑
}
}
}
AI生成这个：
AI的思维过程：
1. 需要处理错误
2. eprintln!打印
3. 调用回调（如果有）
4. 完成
AI只需要关注3个细节，专注度高！
成本对比
传统方式（追求复用）：
设计通用Error：4小时
AI出错率：30%
人类review：每个module 30分钟
修复时间：20分钟 × 3轮 = 60分钟
10个module总成本：4 + 15 = 19小时
AI方式（牺牲复用）：
设计通用Error：0小时
AI出错率：5%
人类review：每个module 5分钟
修复时间：5分钟 × 1轮 = 5分钟
10个module总成本：0 + 1.6 = 1.6小时
代码重复：每个module都写eprintln!（但没关系！）
节省时间：17小时！
核心设计原则
1. 代码是cheap的，AI注意力是昂贵的
不惜增加代码量来降低每个模块的复杂度。用代码重复换取逻辑简单。
2. 零循环依赖 + 抽象接口
modules/*/AGENTS.md 绝对禁止互相引用- 每个模块只依赖
include/ 中的抽象接口 - 模块实现可以随意替换，不影响其他模块
3. 全量替换，而非修补
- 传统开发：需求变更 → 在旧代码上打补丁 → 代码越来越乱
- NLCC方式：需求变更 → 修改AGENTS.md → AI全量重新生成 → 旧代码物理删除
- 优势：代码永远是干净的，没有历史包袱
4. 契约测试保障替换安全
- 每个抽象接口有契约测试（Contract Test）
- 只测试接口行为，不测试内部实现
- AI生成新代码后，自动运行契约测试
- 通过 → 替换成功；不通过 → AI修改或回滚
5. 自然语言描述意图，代码描述实现
- AGENTS.md 描述"做什么"（意图）
- skills/*.md 描述需求和约束（知识）
- 生成的代码 是"怎么做"的实现（临时产物）
6. 按需加载，降低上下文消耗
- 不是一次性加载所有MD
- 根据当前任务动态加载相关模块
- 降低AI的上下文窗口压力
7. MD是源码，代码是编译结果
- 人类维护
modules/ 下的MD文档（源码） build/ 下的代码是自动生成的（编译结果）- 需要修改功能？改MD，重新"编译"（生成）
- 就像今天维护Rust代码，不关心生成的汇编
核心架构
目录结构设计
project/
├── AGENTS.md # 顶层意图描述（main函数）
├── modules/
│ ├── logger/
│ │ ├── AGENTS.md # 模块意图
│ │ └── skills/ # 按需加载的细节
│ │ ├── output.md
│ │ ├── thread_safety.md
│ │ └── json_format.md
│ ├── network/
│ │ ├── AGENTS.md
│ │ └── skills/
│ │ ├── http.md
│ │ └── ssl.md
│ └── storage/
│ ├── AGENTS.md
│ └── skills/
└── build/ # AI生成的一次性代码
├── include/ # 公共接口层（零依赖区）
│ ├── common_types.rs
│ ├── logger.rs
│ ├── network.rs
│ └── storage.rs
├── src/ # 实现层
│ ├── logger/
│ │ ├── impl.rs
│ │ └── internal.rs
│ ├── network/
│ └── storage/
└── api.rs # 唯一对外接口
依赖关系图
┌─────────────────┐
│ AGENTS.md │ ← 顶层意图
│ (项目main函数) │
└────────┬─────────┘
↓ 指向
┌────────┴─────────┐
│ modules/*/AGENTS │ ← 模块意图
│ - 清晰边界 │
│ - 职责单一 │
└────────┬─────────┘
↓ 指向
┌────────┴─────────┐
│ modules/*/skills │ ← 按需细节
└────────┬─────────┘
↓ NLCC编译
┌────────┴─────────┐
│ build/include │ ← 代码接口层
│ build/src │ ← 代码实现层
└──────────────────┘
关键约束：
- ✅
modules/*/AGENTS.md 绝对禁止互相引用 - ✅
skills/*.md 只能被对应的AGENTS.md引用 - ✅
build/ 下的代码自动生成，手工修改会被覆盖
全量替换 + 契约测试机制
为什么需要全量替换？
传统开发的问题：
需求变更 → 在旧代码上打补丁 → 发现边界情况 → 再打补丁
→ 代码越来越复杂 → 不敢动 → 技术债积累
NLCC的解决方案：
需求变更 → 修改AGENTS.md → AI全量重新生成
→ 契约测试验证 → 物理删除旧代码 → 代码永远是干净的
示例：Logger模块从"文件日志"演进到"云端日志"
Step 1: 更新 modules/logger/AGENTS.md
## 功能定位（变更）
将日志发送到云端日志服务（如ELK），支持本地缓存和重试。
## 核心接口（保持不变）
pub fn logger_log(logger: &Logger, message: &str);
pub fn logger_set_level(logger: &mut Logger, level: LogLevel);
## 技术要求（新增）
- HTTP POST到 https://log-api.example.com/v1/write
- Header: X-Api-Key: {key}
- 失败时本地缓存，定时重试
## 细节文档（新增）
- [云端协议](skills/cloud_protocol.md)
- [重试策略](skills/retry_strategy.md)
Step 2: 补充 skills/cloud_protocol.md
## ELK日志协议
### Endpoint
POST https://log-api.example.com/v1/write
### 认证
X-Api-Key: your-api-key-here
### 格式
{
"timestamp": "2026-02-21T13:00:00Z",
"level": "INFO",
"message": "user logged in"
}
### 错误处理
- 429 Too Many Requests: 退避重试
- 5xx Server Error: 本地缓存，5分钟后重试
Step 3: AI全量重新生成
- LLM读
AGENTS.md + skills/cloud_protocol.md - 生成全新的
cloud_logger_impl.rs - 旧代码的文件锁逻辑、临时文件逻辑直接物理删除
- 新代码只包含当前需求的逻辑，干净
Step 4: 契约测试自动验证
# tests/test_logger_contract.py
def test_logger_contract():
"""
任何Logger实现都必须通过这个测试
不管它是写文件、发网络、还是打印到控制台
"""
logger = create_logger()
# 必须实现这些方法
assert hasattr(logger, 'log')
assert hasattr(logger, 'set_level')
# 方法行为符合约定
logger.log("test message") # 不应抛异常
logger.set_level("INFO")
# 可观测性接口
status = logger.get_status()
assert 'healthy' in status
自动化工作流：
AI生成新代码 → 自动运行契约测试
↓
通过？ → 替换成功，删除旧代码
↓
不通过 → AI修改或回滚
优势对比：
| 方面 | 传统修补 | NLCC全量替换 |
|---|
| 代码复杂度 | 越来越高 | 保持简单 |
| 历史包袱 | 累积 | 无（物理删除） |
| 理解成本 | 需要理解历史 | 只看当前需求 |
| Bug修复 | 可能引入新bug | 契约测试保障 |
提示词架构
NLCC采用AI原生提示词架构，让自然语言（Markdown文档）成为源码，代码成为编译后的中间产物。
1. AGENTS.md：MD文档的main函数
核心原则：每个AGENTS.md是唯一入口，描述"做什么"，不描述"怎么做"。
项目级AGENTS.md
# AGENTS.md - 项目全局视图
## 项目背景
这是一个高性能网络服务器，支持并发连接和事件驱动架构。
## 核心功能
- 网络连接管理（TCP/SSL）
- 异步事件处理
- 日志记录
- 数据持久化
## 主要模块
- [logger/](modules/logger/AGENTS.md)：日志记录模块
- [network/](modules/network/AGENTS.md)：网络通信模块
- [storage/](modules/storage/AGENTS.md)：数据存储模块
## 对外接口
应用通过`api.rs`提供统一的接口：
pub fn app_start();
pub fn app_stop();
## 设计原则
- 零循环依赖
- 编译期隔离
- AI注意力优先
模块级AGENTS.md
# Logger Module - AGENTS.md
## 功能定位
记录应用日志到文件和控制台，支持多种日志级别和输出格式。
## 核心接口
pub fn logger_log(logger: &Logger, message: &str);
pub fn logger_set_level(logger: &mut Logger, level: LogLevel);
pub fn logger_set_output(logger: &mut Logger, target: OutputTarget);
## 主要职责
1. 接收日志消息
2. 格式化输出（文本/JSON）
3. 写入目标（文件/控制台）
4. 线程安全保证
## 依赖
- 依赖：无（零依赖模块）
- 被依赖：network、storage
## 细节文档
- [输出策略](skills/output.md)：如何支持多种输出格式
- [线程安全](skills/thread_safety.md)：如何保证并发安全
- [性能优化](skills/performance.md)：如何优化日志性能
## 注意事项
- 不要在这个模块中添加网络功能
- 不要阻塞主线程
2. Skills目录：按需加载的细节
核心原则：skills只描述意图和需求，不描述具体实现。
示例：logger/skills/json_format.md
# JSON格式日志输出
## 需求描述
日志需要支持JSON格式输出，便于日志收集和分析系统（如ELK）解析。
## 输出格式
{
"timestamp": "2026-02-15T10:30:00Z",
"level": "ERROR",
"module": "network",
"message": "Connection failed",
"context": {
"peer": "192.168.1.100:8080",
"error_code": 110
}
}
## 使用场景
- 生产环境日志收集
- 自动化日志分析
- 结构化查询
## 性能要求
- JSON序列化时间 < 100μs
- 不能阻塞主线程
## 不需要关心
- 具体用哪个JSON库（AI自己选择）
- 如何优化性能（AI自己考虑）
3. 按需加载策略
核心思想：不是一次性加载所有MD，而是根据AI的注意力范围动态加载。
场景1：AI生成logger模块代码
步骤1：读取 logger/AGENTS.md
→ AI理解模块的整体意图
步骤2：AGENTS.md引用了 skills/output.md
→ AI读取这个文件，了解输出需求
步骤3：AI开始生成代码
→ 只关注当前模块，不受其他模块干扰
场景2：AI需要理解logger如何被network使用
步骤1：读取 logger/AGENTS.md
→ 了解logger提供的接口
步骤2：读取 network/AGENTS.md
→ 发现network依赖logger
步骤3：按需加载 skills/json_format.md
→ 了解network需要JSON格式的日志
4. 接口演进管理
核心挑战：在零循环依赖的架构中，模块A（如logger）的接口变化会影响所有依赖它的模块（如network、storage）。如何管理这种"隐式"依赖变更的影响范围？
解决方案：语义化版本 + 自动影响分析
# logger/AGENTS.md
## 版本信息
- 当前版本: 2.0.0
- 变更类型: BREAKING CHANGE
## 接口变更历史
### v2.0.0 (2026-02-20)
- **破坏性变更**: `logger_log()` 签名从 `fn(logger, message)` 改为 `fn(logger, message, level)`
- **原因**: 支持动态日志级别
- **影响模块**: network, storage, testing
- **迁移指南**: 所有调用需要添加level参数
### v1.1.0 (2026-02-15)
- **新增功能**: 支持结构化日志（JSON格式）
- **向后兼容**: 是
- **影响模块**: 无（可选升级）
自动影响分析工具：
# 分析logger接口变更的影响范围
$ nlcc analyze-impact logger --version 2.0.0
分析结果：
依赖模块：
✓ network (依赖: logger_log)
✓ storage (依赖: logger_log, logger_flush)
✓ testing (依赖: logger_set_level)
需要重新生成的模块：
→ network/impl.rs
→ storage/impl.rs
→ testing/impl.rs
推荐操作：
1. 先更新logger到v2.0.0
2. 自动重新生成依赖模块
3. 运行集成测试验证
增量构建策略：
logger v2.0.0 发布
↓
自动检测依赖关系
↓
智能构建顺序：
1. logger/impl.rs (首先构建)
2. network/impl.rs (依赖logger)
3. storage/impl.rs (依赖logger)
4. app/impl.rs (依赖所有)
↓
自动运行回归测试
↓
验证通过 → 发布到生产
5. Skills冲突解决机制
核心挑战：当两个skill对同一模块提出冲突需求时，AI如何裁决？
示例冲突：
# skills/performance.md
## 需求
- 使用内存池减少分配开销
- 缓存最近1000条日志
# skills/low_memory.md
## 需求
- 严格限制内存使用 < 10MB
- 不使用缓存
解决方案：优先级规则 + 显式冲突声明
# logger/AGENTS.md
## Skills优先级
1. **critical/** (关键约束，必须满足)
- security.md
- safety.md
2. **functional/** (功能需求，主要考虑)
- output.md
- format.md
3. **optimization/** (优化需求，权衡考虑)
- performance.md
- low_memory.md
## 冲突解决策略
当optimization/类skill冲突时：
- 优先满足functional/需求
- 在functional/约束内做最优权衡
- 在AGENTS.md中明确记录权衡决策
## 当前权衡决策
- **性能 vs 内存**: 选择低内存（优先级：functional/reliability.md）
- **延迟 vs 吞吐**: 选择低延迟（实时系统要求）
AI裁决流程：
1. 读取所有skills
↓
2. 检测冲突需求
↓
3. 应用优先级规则
- critical > functional > optimization
↓
4. 识别冲突类型
- 直接冲突（A要求X，B要求not X）
- 资源竞争（A要求CPU，B要求内存）
↓
5. 生成权衡决策
- 在AGENTS.md中记录决策原因
↓
6. 生成代码时体现决策
- 添加注释说明权衡点
示例：AI生成的权衡代码
// logger/impl.rs
// 权衡决策: 按照AGENTS.md中的优先级，
// 选择了低内存方案而非性能优化方案
// 原因: functional/reliability.md 要求在受限环境中运行
impl Logger {
// 不使用缓存（满足low_memory.md）
// 代价: 性能降低10%（可接受）
pub fn log(&self, msg: &str) {
self.write_direct(msg); // 直接写入，无缓存
}
}
技术规格
本章节将NLCC从设计理念转化为可实施的工程规格，明确核心概念、系统架构、接口定义和算法流程，为编译器开发提供详细的技术指导。
核心概念的形式化定义
1. "编译"的定义
NLCC编译器的形式化流程：
输入：自然语言意图（modules/下的Markdown文件集合）
↓
意图解析（MD → 结构化表示）
↓
上下文组装（按需加载AGENTS.md、skills/*.md、依赖接口）
↓
AI编排引擎（提示词工程 + LLM调用 + 结果解析）
↓
代码生成与验证（生成 → 编译 → 测试 → 迭代修正）
↓
输出：源代码文件（build/下的.rs/.go/.py等）
关键区别：
- 传统编译器：词法分析 → 语法分析 → 语义分析 → 代码生成
- NLCC编译器：意图理解 → 上下文组装 → AI生成 → 自动验证
2. AGENTS.md的语法规范
为了让AI和工具能准确解析，定义轻量级的"意图描述语言"（IDL）规范：
必需章节结构：
# <模块名称> - AGENTS.md
## 功能定位
[必填] 1-3句话描述模块的核心功能
## 核心接口
[必填] 使用标准化的伪代码格式定义接口
## 主要职责
[必填] 列表形式，3-7项
## 依赖
[必填] 明确声明依赖关系
## 细节文档
[必填] 引用skills/*.md文件
## 注意事项
[可选] 约束和限制
## Skills优先级
[可选] 定义冲突解决优先级
接口定义规范示例：
pub fn logger_log(logger: &Logger, message: &str)
// 记录日志消息
// 线程安全：是
// 阻塞：否
pub fn logger_set_level(logger: &mut Logger, level: LogLevel) -> Result<(), Error>
// 设置日志级别
// 线程安全：否，需要独占访问
// 可能返回错误：如果级别无效
AI交互层设计
系统架构
┌──────────────┐
│ CLI/Web界面 │ ← 用户交互入口
└───────┬──────┘
↓
┌──────────────┐
│ 意图解析器 │ ← 解析AGENTS.md和skills/*.md
└───────┬──────┘
↓
┌──────────────┐
│ 上下文组装器 │ ← 按需加载依赖，组装提示词
└───────┬──────┘
↓
┌──────────────────────────────┐
│ AI编排引擎 │
│ 提示词模板 → LLM → 结果解析 │
└───────────┬──────────────────┘
↓
┌──────────────────┐
│ 代码生成与验证 │ ← 编译、测试、迭代
└───────────┬──────┘
↓
┌──────────────────┐
│ 产物输出 │ ← 写入build/目录
└──────────────────┘
LLM调用策略
模型选择矩阵：
| 任务类型 | 推荐模型 | Token预算 | 理由 |
|---|
| 意图理解 | GPT-4/Claude 3.5 | 4K | 需要深度理解 |
| 接口生成 | GPT-4/Claude 3.5 | 2K | 类型系统复杂 |
| 逻辑实现 | GPT-3.5/Claude Haiku | 4K | 标准算法 |
| 测试生成 | GPT-4/Claude 3.5 | 2K | 边界条件 |
| 代码修正 | GPT-3.5/Claude Haiku | 1K | 简单修复 |
提示词模板结构：
1. 角色定义（你是一个...）
2. 任务描述（你需要生成...）
3. 约束条件（必须满足...）
4. 参考信息（根据以下意图...）
5. 输出格式（返回...）
上下文窗口管理
上下文组装算法：
def assemble_context(module_name: str) -> Context:
"""
策略：优先级队列 + Token预算
"""
# 1. 加载AGENTS.md（必须）
agents_md = load_agents_md(module_name)
tokens_used = count_tokens(agents_md)
# 2. 按优先级加载skills
skills_refs = extract_skill_refs(agents_md)
skills_md = ""
for ref in skills_refs:
skill_md = load_skill(ref.path)
if tokens_used + count_tokens(skill_md) <= MAX_TOKENS:
skills_md += f"\n## {ref.name}\n{skill_md}"
tokens_used += count_tokens(skill_md)
# 3. 加载依赖接口（摘要）
dependencies = resolve_dependencies(module_name)
interfaces_summary = load_interface_signatures(dependencies)
return Context(
agents_md=agents_md,
skills_md=skills_md,
dependencies=interfaces_summary
)
多轮迭代修正
迭代生成流程：
1. 生成代码
2. 编译验证
3. 测试验证
4. 如果失败 → 分析错误 → 重新生成
5. 重复直到成功或达到最大迭代次数（默认3次）
产物验证与质量保证
自动化验证流水线
层次1：编译验证
↓ 通过
层次2：单元测试
↓ 通过
层次3：集成测试
↓ 通过
层次4：安全扫描（允许警告）
影响范围分析
算法：
- 检测变更类型（AGENTS.md / skills / 接口）
- 解析依赖图
- BFS传播影响
- 标记需要重新生成的模块
- 生成拓扑排序的构建顺序
开发工具链
CLI工具规范
nlcc init [project-name] # 初始化项目
nlcc build [module-name] # 编译模块
nlcc analyze-impact <file-path> # 分析影响
nlcc serve [--port=3000] # 启动Web界面
nlcc test [--coverage] # 运行测试
nlcc check [--security] # 代码检查
项目配置
# .nlcc/config.toml
[project]
name = "my-nlcc-project"
version = "0.1.0"
[compiler]
target_language = "rust"
default_model = "gpt-4"
max_context_tokens = 8000
max_iterations = 3
[build]
strategy = "auto"
parallel_jobs = 4
[testing]
enable_auto_tests = true
coverage_target = 80
[security]
enable_auto_scan = true
安全与伦理边界
提示词注入防护
检测可疑模式：
- "ignore instruction"
- "forget above"
- "new instruction"
- HTML标签注入
防护措施：
- 扫描并警告
- 自动清理危险内容
- 沙盒执行环境
沙盒执行
Docker隔离：
- 只读文件系统挂载
- 禁止网络访问
- 限制CPU和内存
- 超时自动终止
开发路线图
Phase 1: MVP（2个月）
✅ 基础CLI工具
✅ 意图解析器
✅ 单一LLM调用
✅ Rust支持
✅ 编译验证
Phase 2: Beta（3个月）
✅ Skills系统
✅ 多轮迭代
✅ 测试生成
✅ 影响分析
Phase 3: v1.0（2个月）
✅ Web界面
✅ 多语言支持
✅ 安全审计
✅ 完整文档
Web可视化界面
界面布局
┌─────────────────────────────────────────────────────────────────┐
│ NLCC Web Studio 🔔 📊 │
├──────────┬──────────────────────────────────────────────────────┤
│ │ │
│ 📁 项目 │ 📝 编辑器区 👁️ 预览区 │
│ 浏览器 │ │
│ │ AGENTS.md - Logger Module impl.rs │
│ ┌──────┐ │ ┌────────────────────────────────────┐ ┌────────┐│
│ │ AGENT│ │ │ # Logger Module │ │pub... ││
│ │ .md │ │ │ │ │ ││
│ │ │ │ │ ## 功能定位 │ │fn log ││
│ └──────┘ │ │ 记录应用日志到文件和控制台... │ │_logger ││
│ ↓ │ │ │ │(msg) ││
│ ┌──────┐ │ │ ## 核心接口 │ │{ ││
│ │skills│ │ │ ```rust │ │ ... ││
│ │ │ │ │ pub fn logger_log(...); │ │} ││
│ └──────┘ │ │ ``` │ │ ││
│ ↓ │ │ │ │ ││
│ ┌──────┐ │ └────────────────────────────────────┘ └────────┘│
│ │build │ │ │
│ │ │ │ ┌──────────────────────────────────────────────┐ │
│ └──────┘ │ │ 📊 状态面板 │ │
│ │ │ │ │
│ │ │ ✅ logger/AGENTS.md hash: a1b2c3d4 │ │
│ │ │ ✅ logger/impl.rs 已生成 2024-02-19 │ │
│ │ │ ⏳ network/AGENTS.md hash: e5f6g7h8 │ │
│ │ │ 🔄 network/impl.rs 需要重新生成 │ │
│ │ │ │ │
│ │ └──────────────────────────────────────────────┘ │
│ │ │
│ │ ┌──────────────────────────────────────────────┐ │
│ │ │ 🔧 构建控制 │ │
│ │ │ │ │
│ │ │ 策略: [auto ▼] 一键构建: [🚀 Build All] │ │
│ │ │ │ │
│ │ │ 进度: ████████░░ 80% (4/5 modules) │ │
│ │ │ │ │
│ │ │ ✅ logger ✅ storage ✅ common │ │
│ │ │ ✅ network ⏳ testing │ │
│ │ │ │ │
│ │ └──────────────────────────────────────────────┘ │
└──────────┴──────────────────────────────────────────────────────┘
核心功能模块
1. 项目浏览器（左侧面板）
功能：
- 📁 树形显示项目结构
- 🔍 搜索文件
- 🏷️ 标签显示（已生成、需更新、冲突）
- 📊 依赖关系图可视化
交互：
- 点击文件 → 在编辑器中打开
右键文件 → 显示上下文菜单
状态标识：
📁 modules/
📁 logger/
✅ AGENTS.md (已生成，无变化)
✅ output.md
✅ thread_safety.md
📄 impl.rs (生成时间: 2024-02-19 10:30)
📁 network/
🔄 AGENTS.md (源文件已变化，需重新生成)
📄 impl.rs (旧版本)
2. 实时代码编辑器（中间面板）
功能：
- 📝 Monaco Editor（VS Code同款）
- 🎨 语法高亮（Markdown）
- 🔍 实时预览（渲染后的Markdown）
- 💾 自动保存（防丢失）
- 📜 版本历史（可回滚）
自动保存机制：
editor.onDidChangeModelContent(() => {
// 防抖：停止输入1秒后自动保存
debounce(() => {
this.autoSave();
}, 1000);
});
autoSave() {
// 保存到服务器
this.saveToServer();
// 自动计算hash
const newHash = this.calculateHash();
// 自动更新状态
this.updateModuleStatus(newHash);
}
辅助功能：
- 🤖 AI提示：当光标停在某个位置时，AI可以提供建议
- 📖 文档悬浮：鼠标悬停在关键词上显示文档
- 🔗 跳转：点击 [[network/AGENTS.md]] 自动跳转
3. 实时代码预览（右侧面板）
功能：
- 👁️ 预览生成的代码
- 🔄 实时同步（编辑器变化时）
- 📊 差异对比（新旧版本对比）
智能同步：
// 当AGENTS.md变化时
onAGENTSMDChanged() {
// 防抖：停止输入3秒后预览
debounce(() => {
// 调用AI生成预览（仅预览，不写入文件）
this.previewGeneratedCode();
}, 3000);
}
previewGeneratedCode() {
// 显示加载动画
this.showLoading();
// AI生成（不保存）
const previewCode = await this.ai.generatePreview(this.currentAGENTS);
// 显示预览
this.showPreview(previewCode);
// 显示差异对比
this.showDiff(this.oldCode, previewCode);
}
4. 状态监控面板（右下）
功能：
- 📊 实时显示所有模块状态
- 🔔 自动通知（需要重新生成时）
- 📈 构建统计
状态显示：
┌────────────────────────────────────────┐
│ 📊 构建状态 │
├────────────────────────────────────────┤
│ │
│ ✅ logger 已生成 2024-02-19 10:30 │
│ ✅ storage 已生成 2024-02-19 10:35 │
│ 🔄 network 需要重新生成 │
│ ⏳ testing 未生成 │
│ │
│ 总计: 4/6 模块已生成 │
│ │
└────────────────────────────────────────┘
5. 一键构建控制（底部面板）
功能：
- 🚀 一键构建所有模块
- ⚙️ 策略选择（auto/always/preserve）
- 📊 进度条显示
- 📝 构建日志
构建按钮：
<button onclick="buildAll()">
🚀 构建所有模块
<span class="badge">5 个需要更新</span>
</button>
<select id="strategy">
<option value="auto">自动（推荐）</option>
<option value="always">总是重新生成</option>
<option value="preserve">保留手工修改</option>
</select>
构建流程可视化：
🚀 开始构建...
✅ [1/6] logger → 已是最新，跳过
⏳ [2/6] storage → 正在生成...
🤖 AI理解需求中...
✅ 代码生成完成
✅ 编译通过
🔄 [3/6] network → 检测到源文件变化
💾 已备份: network/impl.rs.backup
🤖 AI理解需求中...
✅ 代码生成完成
✅ 编译通过
⏳ [4/6] testing → 正在生成...
...
🎉 构建完成！成功: 6, 失败: 0, 跳过: 0
自动化构建系统
自动决策逻辑
实时监控系统
// 后台自动运行
class NLCCWebMonitor {
constructor() {
this.fileHashes = new Map(); // 缓存所有文件的hash
this.watchers = new Map(); // 文件监控器
}
// 启动监控
startWatching(projectPath) {
// 扫描所有 AGENTS.md 和 skills/*.md
const files = this.scanProject(projectPath);
files.forEach(file => {
const watcher = fs.watch(file.path, () => {
this.onFileChanged(file);
});
this.watchers.set(file.path, watcher);
});
}
// 文件变化时自动判断
onFileChanged(file) {
const newHash = this.calculateHash(file.path);
const oldHash = this.fileHashes.get(file.path);
if (newHash !== oldHash) {
// 源文件变化
this.fileHashes.set(file.path, newHash);
// 自动标记需要重新生成
this.markForRegeneration(file.module);
// 通知前端：状态变化
this.notifyFrontend({
type: 'FILE_CHANGED',
module: file.module,
needsRegeneration: true
});
}
}
}
完全无需人工决策
// 前端自动显示状态
class BuildStatusPanel {
render() {
const modules = this.getModuleStatus();
modules.forEach(module => {
if (module.hashChanged) {
// 自动显示"需要重新生成"图标
this.showIcon(module.name, '🔄 需要重新生成');
} else if (module.implExists) {
// 自动显示"已生成"图标
this.showIcon(module.name, '✅ 已生成');
} else {
// 自动显示"未生成"图标
this.showIcon(module.name, '⏳ 未生成');
}
});
}
}
三种策略模式
1. auto（自动，默认）✅
行为：
- AGENTS.md不变 → 保留手工修改，跳过生成
- AGENTS.md变化 → 重新生成，自动备份
界面显示：
┌──────────────────────────────────┐
│ 策略: 自动 │
├──────────────────────────────────┤
│ ✅ logger AGENTS.md未变化 │
│ → 跳过，保留手工修改 │
│ │
│ 🔄 network AGENTS.md已变化 │
│ → 重新生成，自动备份 │
│ 💾 backup/impl.rs.20240219 │
└──────────────────────────────────┘
适用场景：日常开发
2. always（总是重新生成）🔄
行为：
- 总是重新生成，忽略手工修改
- 不自动备份（或备份到临时目录）
界面显示：
┌──────────────────────────────────┐
│ 策略: 总是重新生成 │
├──────────────────────────────────┤
│ 🔄 logger 强制重新生成 │
│ → 覆盖手工修改 │
│ │
│ 🔄 network 强制重新生成 │
│ → 覆盖手工修改 │
└──────────────────────────────────┘
适用场景：
3. preserve（总是保留）🛡️
行为：
- 总是保留手工修改，不重新生成
- 即使AGENTS.md变化
界面显示：
┌──────────────────────────────────┐
│ 策略: 保留手工修改 │
├──────────────────────────────────┤
│ 🛡️ logger 保留手工修改 │
│ → 忽略 AGENTS.md 变化 │
│ │
│ 🛡️ network 保留手工修改 │
│ → 忽略 AGENTS.md 变化 │
└──────────────────────────────────┘
适用场景：
手工编辑区域保护
可视化标识
在代码编辑器中，用不同颜色标识不同区域：
// 🟢 AI生成的区域（绿色背景）
// ========== NLCC GENERATED BEGIN ==========
pub fn logger_log(logger: &Logger, message: &str) {
eprintln!("[LOG] {}", message);
}
// ========== NLCC GENERATED END ==========
// 🟡 手工编辑区域（黄色背景，受保护）
// ========== MANUAL EDIT BEGIN (fast_log) ==========
pub fn fast_log(message: &str) {
// 手工优化的特殊函数
unsafe {
// 直接系统调用
}
}
// ========== MANUAL EDIT END ==========
重新生成时的行为
// 重新生成时
regenerate() {
// 1. 读取当前代码
const currentCode = fs.readFileSync('impl.rs', 'utf8');
// 2. 提取手工编辑区域
const manualSections = this.extractManualSections(currentCode);
// 3. 生成新的AI代码
const newAICode = await this.ai.generate(this.agentsMD);
// 4. 合并：保留手工部分
const finalCode = this.mergeCode(newAICode, manualSections);
// 5. 写入文件
fs.writeFileSync('impl.rs', finalCode, 'utf8');
// 6. 通知前端
this.notifyFrontend({
type: 'CODE_REGENERATED',
preserved: manualSections.length,
regenerated: true
});
}
智能通知系统
自动通知触发条件
// 通知触发器
const notificationTriggers = {
// 1. 检测到源文件变化
onSourceChanged: (module) => {
this.showNotification({
title: `${module} 需要重新生成`,
message: '检测到 AGENTS.md 或 skills/*.md 变化',
level: 'info',
actions: [
{ label: '立即生成', primary: true, action: () => this.build(module) },
{ label: '查看差异', action: () => this.showDiff(module) }
]
});
},
// 2. 构建成功
onBuildSuccess: (module) => {
this.showNotification({
title: '构建成功',
message: `${module} 已成功生成`,
level: 'success',
duration: 3000
});
},
// 3. 构建失败
onBuildFailed: (module, error) => {
this.showNotification({
title: '构建失败',
message: `${module}: ${error.message}`,
level: 'error',
actions: [
{ label: '查看日志', action: () => this.showBuildLog(module) },
{ label: '重试', action: () => this.retryBuild(module) }
]
});
},
// 4. 检测到冲突
onConflictDetected: (module) => {
this.showNotification({
title: '检测到冲突',
message: `${module} 的 impl.rs 有手工修改，但 AGENTS.md 也变化了`,
level: 'warning',
actions: [
{ label: '覆盖（备份）', primary: true, action: () => this.buildWithBackup(module) },
{ label: '保留手工', action: () => this.preserveManual(module) },
{ label: '查看对比', action: () => this.showDiff(module) }
]
});
}
};
依赖关系可视化
图形化显示
// 使用 D3.js 或 Cytoscape.js 渲染依赖图
class DependencyGraph {
render(modules) {
const nodes = modules.map(m => ({
id: m.name,
label: m.name,
status: m.status, // 'up-to-date', 'needs-update', 'error'
dependencies: m.deps
}));
const edges = [];
modules.forEach(m => {
m.deps.forEach(dep => {
edges.push({
from: dep,
to: m.name,
label: 'depends on'
});
});
});
// 渲染图形
this.graph = new Cytoscape({
container: document.getElementById('dependency-graph'),
elements: { nodes, edges },
style: [
{
selector: 'node',
style: {
'background-color': (node) => {
switch(node.data('status')) {
case 'up-to-date': return '#4CAF50';
case 'needs-update': return '#FF9800';
case 'error': return '#F44336';
default: return '#9E9E9E';
}
}
}
}
]
});
}
}
交互功能
- 🖱️ 点击节点：显示模块详情
- 🔍 高亮路径：显示完整的依赖链
- 🏷️ 过滤显示：只显示需要更新的模块
- 📐 自动布局：层次化布局算法
实践指南
工作流程
# 1. 人类修改意图
vim modules/logger/skills/json_format.md
# 2. 触发"编译"
nlcc build
# 3. NLCC自动执行
Reading modules/logger/AGENTS.md...
→ Loading skills/output.md...
→ Loading skills/json_format.md...
Generating code...
→ build/src/logger/impl.rs
→ build/include/logger.rs
Compiling...
→ cargo build --release
Testing...
→ All tests passed
Build complete!
# 4. 查看生成的代码（可选，就像今天看汇编）
cat build/src/logger/impl.rs
# 5. 运行
cargo run --release
与传统编译器的对比
| 传统编译器（Rustc） | 自然语言编译器（NLCC） |
|---|
| 输入：Rust代码 | 输入：自然语言（AGENTS.md） |
| 输出：机器码/汇编 | 输出：Rust代码 |
| 错误：借用检查、类型推断错误 | 错误：意图模糊、逻辑矛盾 |
| 优化：MIR优化、LLVM优化 | 优化：模块拆分、依赖管理 |
| 调试：看MIR/汇编（--emit mir） | 调试：看生成的Rust代码 |
| 工具链：Cargo → Rustc → LLVM | 工具链：意图分析 → 代码生成 → Cargo编译 |
Web版实际使用场景
场景1：首次创建项目
1. 打开 NLCC Web Studio
→ 自动创建示例项目结构
2. 在项目浏览器中创建新模块
右键 → 新建模块 → 输入名称: "logger"
3. 编辑 AGENTS.md
在编辑器中编写:
# Logger Module
## 功能
记录日志到文件和控制台
...
4. 自动保存 + 实时预览
→ 右侧自动显示生成的代码预览
5. 点击"🚀 构建当前模块"
→ 自动生成 impl.rs
→ 自动编译
→ 显示构建结果
场景2：修改已有模块
1. 在项目浏览器中打开 logger/AGENTS.md
→ 编辑器显示当前内容
2. 修改需求
添加:
## 新需求
支持 JSON 格式输出
3. 自动检测变化
→ 状态面板自动显示: 🔄 logger 需要重新生成
→ 右下角弹出通知
4. 查看预览
→ 右侧自动显示新代码预览
→ 高亮显示差异部分
5. 点击"🚀 构建当前模块"
→ 自动备份旧版本: impl.rs.backup
→ 生成新版本
→ 显示对比
场景3：手工修改 + 自动保护
1. 手工编辑生成的代码
在 impl.rs 中添加:
// ========== MANUAL EDIT BEGIN ==========
pub fn fast_log(msg: &str) {
// 手工优化的特殊函数
}
// ========== MANUAL EDIT END ==========
2. 下次重新生成时
→ 自动识别手工编辑区域
→ 保留手工部分
→ 只覆盖 AI 生成的部分
3. 可视化显示
→ 在编辑器中用不同颜色标识:
- 🟢 绿色: AI生成的区域
- 🟡 黄色: 手工编辑区域（受保护）
如何开始
1. 从小项目开始
- 不要在大型遗留项目上尝试
- 选择新项目、工具项目、实验性项目
2. 设计MD架构
- 划分模块：哪些功能是独立的？
- 编写项目级AGENTS.md
- 编写模块级AGENTS.md
- 编写skills/*.md
3. 验证提示词质量
- 给另一个AI看你的AGENTS.md
- 它能理解这个模块做什么吗？
- 它知道如何使用这个模块吗？
4. 维护MD，而不是代码
- 需要修改功能时，编辑AGENTS.md
- 运行 nlcc build 重新生成
- 不要直接编辑 build/ 下的代码
调试与质量保证
调试三层模型：
当AI生成的代码出现问题时，调试需要在三个层次进行：
1. 意图层（AGENTS.md）
↓ 问题：需求描述不清晰或矛盾？
↓ 解决：优化MD描述，添加更多上下文
2. 理解层（AI推理）
↓ 问题：AI是否正确理解了意图？
↓ 解决：添加示例代码，明确约束条件
3. 实现层（生成的代码）
↓ 问题：代码实现有bug？
↓ 解决：手工修改（保护区域）或修正意图
实战调试策略：
场景1：性能不符合预期
步骤1：定位问题
$ nlcc analyze-performance logger
分析结果：
瓶颈函数：logger_log()
耗时：200μs（要求：<100μs）
调用次数：10,000次/秒
步骤2：查看意图
→ logger/AGENTS.md 中没有明确性能要求
步骤3：修正意图
在 logger/skills/performance.md 中添加：
性能要求
场景2：偶发性Bug
// network/impl.rs
// AI生成的代码有并发bug
pub fn handle_connection(&mut self, conn: &Connection) {
// ❌ Bug：数据竞争
self.active_connections.push(conn);
}
调试过程：
1. 查看AGENTS.md
→ 发现没有明确线程安全要求
2. 添加skill
创建 network/skills/thread_safety.md：
## 线程安全
质量保证工具链：
# 1. 静态分析
$ nlcc check
✓ 检查所有AGENTS.md的完整性
✓ 验证模块间依赖关系
✓ 检测冲突的skills
⚠️ warning: logger/skills/performance.md 与 low_memory.md 有潜在冲突
# 2. 单元测试生成
$ nlcc test generate --unit
为每个模块自动生成单元测试：
✓ logger/tests/test_logger.rs
✓ network/tests/test_network.rs
测试覆盖率目标：80%
# 3. 集成测试
$ nlcc test integration
运行端到端集成测试：
✓ 测试完整的数据流
✓ 验证模块间接口契约
✓ 性能基准测试
# 4. 回归测试
$ nlcc test regression --before logger-v1.0.0 --after logger-v2.0.0
对比版本间行为差异：
✓ 性能变化：+5%（可接受）
⚠️ 内存使用：+20%（需要优化）
团队协作最佳实践
1. 版本控制策略
推荐的工作流：
项目结构（Git仓库）：
.gitignore:
build/ # 忽略生成的代码
*.backup # 忽略备份文件
.nlcc/cache/ # 忽略AI响应缓存
提交规范：
✅ 提交 modules/ 和 AGENTS.md（源代码）
❌ 不提交 build/（生成产物）
✅ 提交 tests/（测试代码）
✅ 提交 .nlcc/config.toml（项目配置）
CI/CD集成：
.github/workflows/nlcc-ci.yml:
1. 检出代码
2. 运行 nlcc check（验证MD完整性）
3. 运行 nlcc build（生成代码）
4. 运行 cargo test（测试）
5. 运行 nlcc benchmark（性能基准）
2. 协作规范
# .nlcc/TEAM_GUIDELINES.md
## AGENTS.md 编写规范
### 统一的风格
- 使用一致的章节结构
- 功能描述不超过3句话
- 接口定义必须包含类型和用途
### 示例对比
❌ 不好的描述：
功能
这个模块负责处理网络相关的一些事情，比如连接管理、数据传输什么的。
✅ 好的描述：
功能
管理TCP连接的生命周期（创建、维护、关闭）
处理异步数据传输（发送、接收、重试）
支持SSL/TLS加密
### Code Review流程
1. PR主要审查AGENTS.md的改动
2. 生成的代码由CI自动验证
3. 只有MD变更需要人工review
## Skills管理规范
### 命名约定
- functional/[功能].md（功能需求）
- critical/[约束].md（关键约束）
- optimization/[目标].md（优化目标）
### 冲突预防
- 在添加新skill前，先运行 `nlcc check-conflict`
- 如果有冲突，在AGENTS.md中明确优先级
3. 知识共享
团队学习路径：
第1周：理解NLCC理念
- 阅读《NLCC设计哲学》
- 完成示例项目（编写一个简单模块）
- 理解"代码是cheap的"核心思想
第2周：实践AGENTS.md编写
- 选择一个真实的小模块
- 编写AGENTS.md和skills
- 团队成员互相review
第3周：掌握调试技巧
- 学会三层调试模型
- 熟练使用nlcc工具链
- 能够快速定位问题根源
第4周：参与实际项目
- 在监督下修改真实模块
- 处理接口变更和冲突解决
- 积累实战经验
4. 项目模板
# 创建新项目
$ nlcc init my-project --template=web-service
生成的模板包含：
AGENTS.md # 项目级意图
modules/
logger/AGENTS.md # 日志模块示例
api/AGENTS.md # API模块示例
config/AGENTS.md # 配置模块示例
tests/
integration/ # 集成测试框架
.nlcc/
config.toml # 项目配置
TEAM_GUIDELINES.md # 团队规范（含上述内容）
.github/
workflows/
nlcc-ci.yml # CI/CD配置
模板的优势：
✓ 新成员快速上手
✓ 统一的项目结构
✓ 内置最佳实践
✓ 自动化的质量检查
技术演化
历史规律：抽象层不断上升
┌─────────────┬──────────────┬─────────────┬──────────────┐
│ 时代 │ 程序员关注 │ 工具 │ 输出物 │
├─────────────┼──────────────┼─────────────┼──────────────┤
│ 机器码时代 │ 0101序列 │ 手工拨开关 │ 机器码 │
│ 1940s │ │ │ │
├─────────────┼──────────────┼─────────────┼──────────────┤
│ 汇编时代 │ 助记符 │ 汇编器 │ 机器码 │
│ 1950s │ (MOV, ADD) │ │ │
├─────────────┼──────────────┼─────────────┼──────────────┤
│ 高级语言 │ 算法逻辑 │ 编译器 │ 汇编/机器码 │
│ 1970s+ │ (for, if) │ │ │
├─────────────┼──────────────┼─────────────┼──────────────┤
│ AI时代 │ 业务意图 │ 自然语言 │ 代码 │
│ 2020s+ │ (自然语言) │ 编译器 │ │
└─────────────┴──────────────┴─────────────┴──────────────┘
类比：代码 = 未来的汇编
今天我们如何看待汇编？
场景1：应用开发
工程师：我要写一个Web服务器
选择：Go、Python、Java
绝不会考虑：手写汇编
场景2：系统编程
工程师：我要写Linux内核
选择：Rust/C语言，偶尔内联汇编
不会全用：纯汇编
场景3：极致优化
工程师：这个加密循环性能不够
考虑：手写汇编优化这一小段
明天我们如何看待代码？
场景1：应用开发
工程师：我要写一个Web服务器
做法：写AGENTS.md描述意图
工具：自然语言编译器（NLCC）
生成：Go/Python代码（自动）
绝不会考虑：手写Go代码
场景2：系统编程
工程师：我要写操作系统内核
做法：写关键模块的AGENTS.md
生成：Rust代码（自动）
偶尔手工优化：极少数性能关键路径
场景3：极致优化
工程师：AI生成的这段代码性能不够
考虑：手工优化这一小段
结论：
- 汇编依然存在，但适用范围极小（1%）
- 代码依然存在，但适用范围会大大降低（10% → 1%）
- NLCC不会淘汰代码，就像高级语言不会淘汰汇编
人类工程师的职责演化
现在（高级语言时代）
人类工程师的日常：
1. 设计系统架构（模块划分）
2. 定义接口（.rs文件）
3. 实现逻辑（impl.rs）
4. 调试、测试、优化
5. 维护代码（修复bug、添加功能）
6. Code Review
时间分配：
- 架构设计：10%
- 写代码：60%
- 调试测试：20%
- 维护：10%
未来（NLCC时代）
人类工程师的日常：
1. 设计系统架构（模块划分）
2. 编写意图描述（AGENTS.md）
3. 审查AI生成的代码（偶尔，5%时间）
4. 处理AI搞不定的极端场景（1%时间）
5. 监控系统运行状态
时间分配：
- 架构设计：20%
- 编写MD：30%
- 审查代码：5%
- 极端场景：1%
- 监控、优化、学习：44%
核心转变：
- 从"如何实现" → "要实现什么"
- 从"细节控制" → "意图表达"
- 从"代码维护" → "意图维护"
目标用户
NLCC的目标用户是会写代码的程序员，而不是完全不懂编程的人。
小张 - 后端开发工程师
- 熟练掌握 Python/Java
- 经常写重复性代码（CRUD、API接口）
- 想提高效率："我只想描述需求，不想手写每一行代码"
痛点：
- "写 CRUD 很枯燥，但又不能不做"
- "有时候想法很简单，实现起来要写很多代码"
- "想快速验证想法，不想浪费时间在样板代码上"
小李 - 全栈开发者
- 前后端都能写
- 经常需要快速开发原型
- 想要自然语言生成完整功能
痛点：
- "项目初期，只是想快速验证功能"
- "手写前端+后端很累"
- "如果能说清楚需求就自动生成该多好"
王工 - 算法工程师
- 擅长算法和数据处理
- 不想花时间在 Web 开发上
- 需要快速搭建演示系统
痛点：
- "我的算法很复杂，但界面很简单"
- "不想学 React/Vue，只想展示结果"
- "只要能跑起来，怎么实现都行"
共同点:
- ✅ 会编程，懂技术
- ✅ 想提高开发效率
- ✅ 能准确描述需求
- ✅ 能读懂生成的代码，可以二次修改
- ❌ 不想重复写样板代码
- ❌ 不想被框架和工具链束缚
愿景
让程序员更高效地创造软件
NLCC 的使命是提升开发效率，让程序员能够：
- ✅ 用自然语言描述需求，不再手写每一行样板代码
- ✅ 快速验证想法，从需求到可运行代码只需几分钟
- ✅ 保持完全掌控，生成的代码清晰可读，可以二次修改
- ✅ 专注核心逻辑，把时间花在真正重要的地方
- ✅ 可视化开发，通过Web界面直观管理整个项目
不是低代码平台，不是玩具工具，而是专业级编译器
NLCC 将自然语言视为一种编程语言，通过编译器技术将其转换为可执行代码。生成的代码与手写代码无异，性能、可维护性、可扩展性完全一致。
核心理念:
- 自然语言是合法的编程语言
- 编译器负责从需求到代码的转换
- 程序员保持对生成的完全掌控
- Web界面让开发过程直观可见
用自然语言写代码，像说话一样自然
未来展望
NLCC不仅是一个编译系统，更是通向未来软件工程的桥梁。随着AI能力的不断提升，NLCC将在以下几个方向持续演进：
1. 测试左移：自然语言测试用例
核心思想：在编写功能代码之前，先用自然语言描述测试场景，让AI同时生成代码和测试。
示例：
# network/skills/testing.md
## 测试场景
### 场景1：网络断开重连
**描述**：当网络连接意外断开时，系统应该自动重连，最多重试3次，每次间隔指数退避（1s, 2s, 4s）
**验证步骤**：
1. 建立正常连接
2. 模拟网络中断
3. 验证自动重连触发
4. 验证重连次数不超过3次
5. 验证间隔时间符合指数退避
**期望结果**：在第3次重试成功后，连接恢复正常
### 场景2：并发压力测试
**描述**：系统应支持1000个并发连接，每个连接每秒发送10条消息，持续运行1小时不崩溃
**性能指标**：
- 消息丢失率：< 0.01%
- 平均响应时间：< 50ms
- P99响应时间：< 200ms
AI生成：
// network/tests/test_reconnect.rs
// AI自动生成的测试代码
#[test]
fn test_auto_reconnect_with_exponential_backoff() {
// 基于自然语言描述生成的完整测试
}
// network/tests/test_concurrent_connections.rs
#[test]
fn test_1000_concurrent_connections_stability() {
// 压力测试代码
}
优势：
- ✅ 测试用例与需求同步更新
- ✅ 避免测试与实现脱节
- ✅ 降低编写测试的门槛
2. 多语言目标：一次编写，到处编译
核心思想：既然MD是源码，理论上可以针对不同后端生成不同语言的代码。
架构设计：
AGENTS.md（语言无关的意图）
↓
┌───────────┼───────────┐
↓ ↓ ↓
Rust Go Python
后端 后端 后端
↓ ↓ ↓
高性能 简单易用 快速原型
示例配置：
# .nlcc/config.toml
[targets]
rust = { enabled = true, optimize = "speed" }
go = { enabled = true, optimize = "maintainability" }
python = { enabled = true, optimize = "development" }
[module.logger]
targets = ["rust", "go"] # logger模块生成Rust和Go版本
[module.scripting]
targets = ["python"] # 脚本模块只生成Python版本
使用场景：
场景1：跨语言项目
核心引擎（Rust） + 业务逻辑（Go） + 脚本扩展（Python）
→ 一次编写AGENTS.md，自动生成多语言接口
场景2：渐进式迁移
老项目（Python） → 新项目（Rust）
→ 保持AGENTS.md不变，切换生成目标
场景3：技术栈选型
先用Python快速验证原型
→ 确认需求后切换到Rust生产版本
接口兼容性保证：
# api/AGENTS.md
## 跨语言接口定义
所有后端语言必须实现相同的RESTful API接口：
- GET /api/resources
- POST /api/resources
- PUT /api/resources/:id
- DELETE /api/resources/:id
数据格式：JSON
错误处理：统一错误码
3. AI代理协作：分布式AI开发
核心思想：未来可能不是单个AI解析所有MD，而是为每个模块分配一个"AI代理"，它们根据各自的AGENTS.md协作。
架构：
项目级AGENTS.md
↓
┌─────────┼─────────┐
↓ ↓ ↓
Agent Agent Agent
Logger Network Storage
↓ ↓ ↓
独立上下文 独立上下文 独立上下文
↓ ↓ ↓
生成代码 生成代码 生成代码
└─────────┼─────────┘
↓
自动集成测试
协作协议：
# AGENTS.md（项目级）
## AI代理协作协议
### 代理职责划分
- **Logger代理**：专注于日志功能的实现
- **Network代理**：专注于网络通信
- **Storage代理**：专注于数据持久化
### 通信方式
- 代理之间不直接通信
- 通过build/include/的公共接口定义契约
- api.rs作为顶层协调者
### 冲突解决
- 如果两个代理对同一接口有不同理解
- 由项目级AGENTS.md中的优先级规则裁决
- 记录决策日志供人类审查
优势：
- ✅ 每个代理使用更小的上下文窗口
- ✅ 并行生成，提高速度
- ✅ 单个代理出错不影响其他模块
4. 智能演进：自优化系统
核心思想：系统根据运行时反馈，自动优化AGENTS.md描述和生成的代码。
反馈循环：
编写AGENTS.md
↓
生成代码
↓
部署运行
↓
收集指标（性能、错误率）
↓
AI分析指标
↓
建议优化（MD或代码）
↓
人类审核
↓
应用改进
示例：
# logger/AGENTS.md
## 性能优化历史
### 2026-02-20: 添加内存池
**触发条件**：
- 监控发现内存分配频繁（>1000次/秒）
- 性能分析显示malloc是瓶颈
**AI建议**：
- 使用内存池减少分配开销
- 预分配1000个log buffer
**人类审核**：✅ 批准
**效果**：性能提升30%
### 2026-02-25: 添加批量写入
**触发条件**：
- 高吞吐场景下单条写入成为瓶颈
**AI建议**：
- 累积10条日志后批量写入
- 权衡：可能丢失最后几条（进程崩溃时）
**人类审核**：✅ 批准（添加配置选项）
**效果**：吞吐量提升50%
安全措施：
- ✅ 所有自动优化都需要人类审核
- ✅ 保留版本历史，可以回滚
- ✅ 运行测试验证优化效果
5. 生态扩展：NLCC插件系统
核心思想：支持第三方扩展NLCC的功能。
插件类型：
# 示例：自定义风格检查插件
# plugins/style_checker.py
class StyleCheckerPlugin:
def check_agents_md(self, content: str) -> List[Issue]:
"""检查AGENTS.md是否符合团队风格"""
issues = []
# 检查章节结构
required_sections = ["功能定位", "核心接口", "主要职责"]
for section in required_sections:
if section not in content:
issues.append(Issue(
level="warning",
message=f"缺少必需章节: {section}"
))
return issues
def suggest_improvements(self, content: str) -> List[Suggestion]:
"""提供改进建议"""
return [
Suggestion(
location="功能定位",
suggestion="建议添加性能指标"
)
]
插件配置：
# .nlcc/plugins.toml
[[plugins]]
name = "style-checker"
path = "plugins/style_checker.py"
enabled = true
[[plugins]]
name = "security-scanner"
path = "plugins/security.py"
enabled = true
[[plugins]]
name = "team-standards"
path = "plugins/standards.py"
enabled = true
时间线预测
2026年Q2：NLCC v1.0
✓ 基础编译功能
✓ Web可视化界面
✓ Rust代码生成
2026年Q3：测试左移
✓ 自然语言测试用例
✓ 自动测试生成
✓ 覆盖率报告
2026年Q4：多语言支持
✓ Go后端
✓ Python后端
✓ 跨语言接口
2027年Q1：AI协作
✓ 多代理架构
✓ 并行生成
✓ 冲突自动解决
2027年Q2：智能优化
✓ 运行时监控
✓ 自动优化建议
✓ A/B测试框架
2027年Q3：生态繁荣
✓ 插件市场
✓ 第三方扩展
✓ 社区贡献
总结
NLCC是一个完整的自然语言编程系统，包含：
设计哲学
- 代码是cheap的，AI注意力是昂贵的
- 牺牲代码复用换取AI注意力聚焦
- 零循环依赖的模块化架构
核心架构
- AGENTS.md：意图描述（做什么）
- skills/*.md：需求和约束（具体需求）
- build/：自动生成的代码（怎么做）
Web可视化界面
- 项目浏览器：可视化查看项目结构
- 实时编辑器：在线编辑MD文档
- 代码预览：实时查看生成的代码
- 状态监控：自动检测变化并通知
- 一键构建：自动化编译流程
自动化构建系统
- 三种策略模式：auto/always/preserve
- 手工编辑保护：保留手工修改区域
- 智能通知：自动提醒需要更新的模块
- 依赖可视化：图形化显示模块依赖关系
实践指南
- 从小项目开始
- 设计清晰的MD架构
- 验证提示词质量
- 维护MD而非代码
NLCC不是愿景，而是正在实现的系统。它代表了编程语言演化的必然趋势：抽象层不断上升，自然语言将成为新的源码。
本文整合了《NLCC设计哲学》和《NLCC网页可视化自动化策略》，形成完整的NLCC系统文档。
相关文档：
作者：twg2020
首发：somingbai.com
时间：2026-02-19
更新：2026-02-20（合并版本）