编码七原则在人机协作中的新诠释

前言——

虽然还没有测试资格，但一直在关注论坛，从大家的经验分享和踩坑反馈里收获颇多。

tap制造把游戏创作门槛拉降低到仅需用自然语言表述框架和功能，不过目前来看创作者是需要了解基本编程工程原理的，ai能做的是省去手敲代码或四处复制代码的时间，以及让新人在实战中快速接触熟悉游戏创作流程。

本文基于程序员熟知的 7 个核心编码原则，提炼出适用于 “人类+AI”协作场景的新准则。

Don‘t Repeat Yourself，避免重复代码，通过抽象复用。

在与 AI 协作时，DRY 不仅指代码，更指提示词（prompt）和指令的复用。如果你多次让 AI 做相似的事情（如“格式化日期”“处理用户输入”），应该将这些共性抽象为可复用的提示模板或函数定义。这不仅能减少重复劳动，还能确保 AI 生成的代码风格一致。

· 将常用的功能描述（如错误处理模式、日志格式）保存为提示片段，需要时直接引用。

· 如果 AI 生成了重复代码，主动要求它“提取公共函数”，并引导它遵循 DRY 原则。

Keep It Simple, Stupid，代码应简洁明了，避免过度复杂。

AI 对复杂指令理解能力有限，过于冗长或嵌套的需求易导致它“迷失”。KISS 在这里有两层含义：

1. 提示词要简单：将大任务拆解为多个小步骤，分步引导 AI。

2. 生成的代码要简单：要求 AI 优先给出清晰、直白的实现，而非炫技式的“一行流”。

· 使用“分步式”提示：“第一步，请生成一个函数验证邮箱格式；第二步，在此基础上添加密码强度检查。”

SOLID 是面向对象设计的基石，在人机协作中，它帮助我们设计出易于维护和扩展的代码结构，即使这些代码是 AI 生成的。

· 原意：一个类只负责一件事。

· AI协作：要求 AI 生成的每个函数/类只做一件事。如果 AI 给出的代码同时处理了数据获取、验证和存储，应指出：“请拆分这个函数，让每个函数只负责一个职责。”

· 原意：对扩展开放，对修改关闭。

· AI协作：当需要增加新功能时，引导 AI 通过新增代码而非修改已有代码来实现。

· 原意：子类应能替换父类。

· AI协作：确保 AI 生成的子类不违背父类契约。

· 原意：接口应小而专，避免臃肿。

· AI协作：当 AI 生成一个包含过多方法的接口时，要求它“按功能拆分为多个小接口”，避免实现类被迫实现无用方法。

· 原意：依赖抽象而非具体实现。

· AI协作：引导 AI 基于接口编程。

You Aren’t Gonna Need It，不要实现当前不需要的功能。

AI 有时会“自作聪明”地添加额外功能，YAGNI 提醒我们严格控制需求范围，避免 AI 生成无用的代码，增加维护负担。

· 在提示中明确边界：“只实现核心功能，不要添加未来可能需要的扩展。”

· 若 AI 生成冗余代码，直接删除或要求它简化。

Separation of Concerns，将系统拆分为独立模块，每个模块关注单一领域。

在提示 AI 时，明确划分模块边界，让 AI 一次只生成一个模块。例如，开发天气应用时，先让 AI 生成“数据获取模块”，再生成“存储模块”，最后是“UI 模块”。这样便于人类审查和调整，也避免 AI 混淆不同领域的逻辑。

· 使用“模块化提示”：“请生成一个独立的函数，负责从 API 获取天气数据，不涉及数据存储和显示。”

· 在代码审查中检查模块间耦合度，要求 AI 降低依赖。

Law of Demeter，一个对象应尽可能少地了解其他对象，只与直接朋友通信。

AI 生成的代码可能无意中让高层模块直接操作底层细节。LoD 要求我们约束模块间的交互方式，通过中介解耦。

· 在提示中强调“使用中介模式”或“遵循迪米特法则”。

· 检查 AI 生成的调用链，若发现跨层访问，要求它引入中间层。

Composition Over Inheritance，优先使用组合而非继承来复用功能。

AI 容易生成僵化的继承结构，导致后期难以调整。COI 原则引导 AI 通过组合小功能单元来构建复杂对象，使系统更灵活。

· 在提示中明确：“请用组合方式实现，不要使用继承。”

· 若 AI 生成继承链，可要求它重构为组合模式。