可能受到知识的诅咒影响，最近在半个宇宙用户群里逛的时候发现居然有好多同学对自己开发ACT下不了手，原因可能多种多样，但应该也有一样是不了解最基础的开发套路。

虽然有官方的开发手册在，但是官方手册的体现重点可能是在准确描述方法的签名和用途，而对实际开发的场景和一般的讨论描述较少。所以我就以我的开发经验来写一遍白话一点的基础入门手册，希望能帮到还不敢下手的同学。

知识的诅咒是一种认知偏差，指的是当一个人掌握了某项知识后，就难以想象自己不知道这项知识时的情境，从而无法站在一个无知者的角度去理解和表达。

一个程序从用户的角度抽象一下，可能就3个环节，输入、运算和输出。

输入，就是接收用户的命令，知道用户想要做什么；

运算，就是程序做一系列计算，例如算一个公式，生成一个图片啥的；

输出，就是把结果展示给用户。

当然，输入输出的形式也是经过了几个大的变化，最初是命令行界面（CLI），后面是图形用户界面（GUI）以及现在的用户语言界面（LUI）。

下面是一些例子。

命令行界面

图形用户界面

用户语言界面

从形式上看，LUI像是在GUI上用CLI，也是问它一句，它给回复一句。但是它很不同是，如果你不知道命令和参数，你是用不了CLI的，你不知道Excel上的一些公式，也是用不好Excel的，而LUI大家可能也都体验过了，就用平时和人说话的方式提要求就行了。

从用户角度来说，交互是越来越自然了。而从开发者的角度来说，原来的CLI和GUI开发是我就这些功能，我就这么定的，你不按我的来就用不了，我就报错，很精确。

而LUI是我用户就这么说，什么意思你自己理解，能做就做，做不了也得和我好好说是我自己理解不了。而这就引出了我们在开发ACT时候，应该如何应对。

假设我们要做一个夸夸我的ACT，它实现的就是花式夸赞用户指定的消息。

输入

输入，用web端的星伴对话举例，就是用户输入的消息或者上传的文件。上传的文件通常是提供附属信息，主要还是输入的文本消息。

为了夸人夸到心眼里，我们就让用户告诉程序他是谁，我们指名道姓地夸他。

实现这个，用k_ask_for_answer方法就行，提出一个问题，让用户回答：

name=nact.k_ask_for_answer("亲你叫什么名字呢？")

我回答：王小哈，那这个回答就存到name里面了。

运算

当然，作为一个AI程序，我们不能直接说，王小哈你真棒，kOS提供了一个强大的功能，就是大模型对话，我们把这个任务抛给它就好了：

res = nact.k_semantic_chat("夸我一下，带上我的名字，我是" + name)

上面代码就是提示大模型夸一下我，并且带上上面拿到的名字，输出的结果放在res中。它的内容会是这样，当然每次可能都不一样：

王小哈，你真是一个聪明伶俐、勇敢坚定的人，你总是充满着乐观与活力，让人感染。你的聪慧和勇气总是让人钦佩，你真是个了不起的人！继续加油哦！👍👍👍

输出

夸人的文本生成好了，但是那是后台处理的结果，我们用户还看不到，将这个结果展示给用户是用k_message_send：

nact.k_message_send(res)

用户就能看到回复的消息了。

完整代码

除去都有的框架，核心就3行：

# -*- coding: utf-8 -*-

from kOS import nact

def main():
    # 核心在这里开始
    name=nact.k_ask_for_answer("亲你叫什么名字呢？") # 1 输入
    res = nact.k_semantic_chat("夸我一下，带上我的名字，我是" + name) # 2 运算
    nact.k_message_send(res) # 3 输出
    # 这里结束
main()

正文完了

这应该够简单的了吧核心就3行代码，应该不能再压缩了，这应该算是一个最最简单的入门教程了。当然它是很不完善的，例如用户输入的不是名字怎么处理等还有极大的改进空间。

当然，如果还有其他想了解的开发方面的内容，都可以在群里和评论中提出来，我也可以再写文章分享一下。

对了，这里只介绍了写代码阶段，创建ACT的过程官方已经有了，看这里的2.1节就可以。

后续思路

我认为写程序最重要的是有思路，一个需求来了后，能大概分析出来怎么实现合适，编码反而是比较容易的一环。

而为了能分析出合适的实现方式，需要结合平台提供的能力来考虑，所以就需要大概了解一下运行的平台上提供哪些能力，也就是要大概看一下文档中的方法是做什么的，否则，会出现自己想的设计无法用现有能力实现的问题。

当然，如果遇到目前kOS还不具备的能力，可以向官方提需求，他们的响应速度还是极快的。（网页驱动器能力就是我提的）