业务人员能用 AI 自己做系统吗：从 1 个养殖企业案例看 3 个条件与 5 条边界

作者注：一家约 120 人的养殖企业，总经理借助 AI 编程工具自己搭起了养殖管理系统。本文不复述“人人都能开发”的说法，而是拆解这个案例成立的条件，以及业务人员用 AI 自建系统时仍然绕不开的边界。

2026 年 11 月，乌镇世界互联网大会领先科技奖公布结果，阿里旗下智能体平台 Qoder 是国内唯一获奖的通用 Agent 产品。在相关报道中，有一个案例很容易被转述成“业务人员也能自己做系统”：宁夏养殖企业西鲜记的总经理张立非，用 AI 编程工具在三个多月里搭起了 养殖管理在内的多套业务系统。

这不是一个“零基础一夜变程序员”的故事。 张立非早年在华为、爱立信做过研发，又对自家养殖、屠宰和加工业务非常熟悉。这两个前提，决定了这个案例能说明什么，也决定了它不能说明什么。

核心价值：读完本文，你可以判断自己的业务需求适不适合用 AI 自建，也会知道需求描述、结果检查和持续维护这三道门槛分别在哪里。

业务人员用 AI 自己做系统：案例核心信息速览

先把报道里能确认的事实整理清楚，再讨论它的意义。下表信息均来自极客公园 2026 年 11 月 5 日的报道。

业务人员用 AI 自建系统的真实工作方式

报道里有一个容易被忽略的细节：张立非并不是“说一句话，AI 交付一个系统”。他同时打开多个开发会话，一个任务等待输出时就转到另一个会话；AI 完成修改后，他自己检查结果，再把业务中的新情况补进去。

这其实是一种“业务专家 + AI 执行者”的协作模式。需求拆解、验收判断和迭代方向都留在人手里，AI 承担的是写代码、改代码和运行任务这部分工作。用这个视角重新看案例，结论会更清楚。

业务人员用 AI 做系统：AI 降低了哪些门槛

用 AI 编程自建内部工具，本质上是把原本需要一个小团队完成的工作重新分配。下表对比了传统定制开发中的各个环节，在这个案例里分别由谁承担。

从表里能看出，AI 降低最多的是“把明确的需求变成可运行代码”这一段，以及需求方和开发方之间的沟通损耗。张立非过去最难的，正是缺少一支能把想法写成系统的团队，而这恰好是 AI 编程工具最擅长补位的地方。

不过，需求梳理和结果验收这两头并没有消失，反而更集中地压到了业务负责人身上。报道本身也提到，Qoder 新版本瞄准的是“目标明确、能辨别产出好坏”的人群，这个限定条件很关键。

业务人员用 AI 自建系统的 3 个前提条件

结合案例，可以归纳出三个让这件事做成的前提：

1. 知道问题在哪：张立非清楚“一批羊赚多少钱要等屠宰后才知道”是核心痛点，需求有明确的业务目标。
2. 能把需求说清楚：能描述字段、流程和计算规则，并给出可检查的验收标准，而不只是“帮我做个管理系统”。
3. 能判断产出对不对：研发背景让他能看懂结构、发现逻辑错误，也能在 AI 跑偏时及时纠正。

这三个条件里，第一条是大多数业务负责人都具备的，第二、三条才是真正的分水岭。没有研发背景的人并非做不到，但需要额外投入时间学习，单一案例也无法说明他们的成功率。

🚀 快速开始：如果你想先低成本验证“需求能不能说清楚”，可以用大模型把业务描述整理成结构化需求文档。通过 API易 apiyi.com 用一个 API Key 即可调用多种主流模型，适合先做小范围试验，再决定是否投入正式开发。

业务人员用 AI 自建系统前：先把需求写成规格

很多自建项目失败，不是 AI 写不出代码，而是需求本身含糊。在动手之前，可以先让模型帮你把口语化的业务描述整理成字段、规则和验收条件，自己逐条核对。

下面是一个最简示例，用 OpenAI 兼容接口调用模型，把业务描述转成需求规格：

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

desc = "三个养殖场，按批次记录每天饲料消耗和羊的体重，想在出栏前就知道每批羊大概赚多少钱。"
resp = client.chat.completions.create(
    model="gpt-4o-mini",  # 可替换为平台上可用的其他模型
    messages=[{"role": "user", "content": f"把以下业务需求整理成数据字段、计算规则和验收条件：{desc}"}]
)
print(resp.choices[0].message.content)

import openai
from typing import Optional

SYSTEM_PROMPT = (
    "你是资深业务分析师。请把用户的业务描述整理为：\n"
    "1. 核心数据实体与字段（含单位）\n"
    "2. 计算规则（写出公式）\n"
    "3. 验收条件（每条都必须可被人工检查）\n"
    "4. 需要用户补充确认的问题清单\n"
    "不要假设用户没说过的规则，不确定的地方放进问题清单。"
)

def build_spec(
    business_desc: str,
    model: str = "gpt-4o-mini",
    extra_context: Optional[str] = None,
    max_tokens: int = 1500
) -> str:
    """把口语化业务描述整理成可核对的需求规格"""
    client = openai.OpenAI(
        api_key="YOUR_API_KEY",
        base_url="https://api.apiyi.com/v1"
    )
    content = business_desc
    if extra_context:
        content += f"\n补充背景：{extra_context}"

    try:
        resp = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "system", "content": SYSTEM_PROMPT},
                {"role": "user", "content": content},
            ],
            max_tokens=max_tokens,
        )
        return resp.choices[0].message.content
    except Exception as e:
        return f"调用失败：{e}"

if __name__ == "__main__":
    spec = build_spec(
        business_desc="按批次管理在栏羊，记录每日饲料消耗、体重和生长阶段，"
                      "希望出栏前估算每批羊的成本和利润。",
        extra_context="目前用 Excel 台账，有三个养殖场。"
    )
    print(spec)

这段代码并不能替你开发系统，它的价值在于暴露“我以为说清楚了，其实没说清楚”的地方。模型给出的问题清单越长，说明需求越需要先打磨，再交给 AI 编程工具去实现。

业务人员能不能用 AI 自建系统：适用性判断框架

案例证明了一件事：在条件具备时，业务人员用 AI 自建内部系统是可行的。但它没有证明所有系统都适合这样做。下面这个框架可以帮你区分哪些可以先自建，哪些需要专业团队介入。

西鲜记的养殖管理系统，大体落在左侧：内部使用、用于饲喂和出栏决策、出了问题有人能及时发现。如果你的需求同样属于这一类，用 AI 自建是值得一试的路径；如果多项落在右侧，更稳妥的做法是先用 AI 做原型，把需求打磨清楚，再交给专业团队或采购成熟产品。

业务人员用 AI 自建、采购与定制三条路径对比

把三条路径放在一起，差异会更直观：

三条路径并不互斥。一个常见的组合是：先用 AI 自建跑通流程，验证需求是否真的成立；等系统用户变多、数据变敏感时，再决定是否交给专业团队重构。

业务人员用 AI 自建系统的影响分析

对中小企业负责人的影响

• 需求不再因为缺团队而被搁置：像西鲜记这样技术研发只有一人的企业，过去只能在“不合适的通用软件”和“昂贵的定制方案”之间二选一，现在多了一条可尝试的路径。
• 业务知识的价值被放大：最懂业务的人可以直接把经验写进系统，并随着日常使用不断修改，减少了“需求翻译”带来的信息损耗。
• 负责人的时间成本上升：报道提到张立非是在下班后和出差间隙推进开发的，这部分时间投入同样是成本，不能简单视为“0 成本”。

对专业开发团队与 IT 部门的影响

• 角色从“写代码”转向“兜底”：业务人员自建的工具多起来以后，安全审查、权限设计、数据备份和系统集成会更需要专业人员介入。
• 影子系统风险上升：如果每个业务部门都各自用 AI 搭工具，数据分散、口径不一、离职后无人维护的问题会随之出现，需要提前建立规范。

这个案例尚未回答的 5 个问题

报道呈现的是成功结果，但对决策者来说，下面这些信息同样重要，目前公开材料并未覆盖：

在这些问题有答案之前，更合理的态度是：把这个案例当作“条件具备时可行”的证据，而不是“谁都能做”的证据。

常见问题 FAQ

业务人员用 AI 自己做系统 Key Takeaways

• 案例成立有前提：主角兼具研发背景和深度业务理解，不能简单等同于“人人可开发”。
• AI 降低的是实现门槛：编码与迭代变快，需求梳理和结果验收仍要靠人。
• 适合先自建的系统：内部使用、数据不敏感、出错可人工纠正的工具。
• 需要专业介入的系统：涉及个人信息、支付、复杂权限和多系统集成的场景。
• 隐性成本不能忽略：时间投入、工具费用、长期维护都应计入决策。
• 先验证再投入：可通过 API易 apiyi.com 低成本调用模型整理需求规格，再决定自建、采购还是定制。

总结

西鲜记的案例说明，当业务负责人既清楚问题在哪，又能说清需求、判断产出时，AI 编程工具可以把过去被搁置的系统需求真正落地。它的核心要点有三条：

1. 门槛下降是真实的：从需求到可运行代码这一段，AI 已经能承担大部分工作。
2. 判断能力不可替代：需求描述、结果检查和持续维护，仍然由懂业务的人负责。
3. 边界要提前划清：数据安全、权限和长期维护，决定了哪些系统可以自建、哪些需要专业团队。

如果你正在考虑用 AI 自建内部工具，建议先从一个出错代价低的小流程开始，用 AI 把需求写成规格、做出原型，再根据结果决定下一步。推荐通过 API易 apiyi.com 快速验证效果，一个 API Key 即可对比多种主流模型。

📚 参考资料

1. 极客公园 – 世界互联网大会领先科技奖背后，Qoder 凭什么拿下中国 AI 编程市场第一：本文案例事实来源
2. 链接： geekpark.net/news/373542
3. 说明： 包含西鲜记养殖管理系统案例，以及吉利、山大华天等企业的 AI 编程实践

作者: APIYI 技术团队
技术交流: 关于模型调用与内部工具接入的问题，欢迎通过 API易 apiyi.com 网站首页联系我们